enum booleans

I don’t think there’s anything wrong with this per se. However....

Just my two cents, but I don’t see the value in adding four additional enums to take the place of true and false, which work perfectly well. This actually consumes a tiny bit of additional memory for code/data and adds nothing to readabilty, IMO. There are some very old languages/frameworks that lack a built in Boolean type where you might need to define an enumeration for true/false, but Monkey C isn’t one of them.

This is also just my personal preference and I’m sure it’s highly debatable, but I try to avoid explicit comparisons with true or false anyway. I write “if (x)” or “if (!x)” (implicit) instead of “if (x == true/false)” (explicit).

This is especially relevant because in general, any value that isn’t null or zero is considered to be “true”. (*)

And all programmers use implicit true/false tests all the time, if you think about it. Everyone writes “if (x > 0)” instead of “if ((x > 0) == true)”....

Another way of looking at this: would it ever make sense for GOOD/YES to be anything other than true? Or for BAD/NO to be anything other than false? If not, then you should be fine just using true and false. Keeping it simple avoids confusion.

(*) Of course, in Monkey C if you want to test for (non)-null or (non)-zero, it’s probably best to do so explicitly, since there are a couple of language bugs/quirks that can cause crashes or unexpected behaviour with such implicit tests. But as long as you know you are dealing with bools, implicit tests work fine.

But is there any concern with future durability with enums (stored as integers) being type compatible with booleans?

You should have no concerns. We recently fixed a bug that prevented enums from being declared to be String, so we do allow it by design.

An enum is not really any different from declaring a constant, except that an enum will get a default value if you don't provide one.If you are afraid of us breaking this, just declare it as a const.

As for the issues brought up by FlowState, yes, there is some overhead associated with using aliases like this. Currently there is a runtime cost associated with doing the lookup of the symbol which you do not need to incur for the literal. There is also the code space that the alias consumes. Ideally the compiler would see the enum declaration and treat it as a constant, but it does not currently do that/

Travis.ConnectIQ just wanted to add: it seems that even a const will take up additional code space compared to a literal, because of the overhead associated with the symbol lookup. This seems to happen even if a const is declared as private (and therefore no outside class would be able to reference it.). I also think I saw some issues 1.5 years ago with const and bitwise operators silently failing/behaving differently, as opposed to bitwise operators + literals. (This is not the bitwise + null issue, or the logical operators <=> bitwise operators issue.)

I thought that I was fairly clear that using an enum over a const won't really get you anything except the default value.

Travis