Bug 3999 and 4261

[bearophile]

Probably each of the ~25 bugs of the short list I have shown here recently need a bit of discussion (also because some of them are little breaking changes over current DMD and/or TDPL). Even if some of them may need to wait in Bugzilla for two years, it's positive to discuss them already. But you can't discuss all of them at the same time.

This is one of them, chosen almost randomly, because it was recently commented by Andrej Mitrovic:
http://d.puremagic.com/issues/show_bug.cgi?id=4261
It's related to:
http://d.puremagic.com/issues/show_bug.cgi?id=3999
http://d.puremagic.com/issues/show_bug.cgi?id=3308

I think bug 3999 shows the root of the situation, so I focus on it (indeed bug 4261 was not in that short list).
In C++0x Foo::V1 == 10 is a compile error, enum and int can't be compared (don't miss the 'class' there):

enum class Foo { V1 = 10 };
int main() {
    int b = Foo::V1 == 10;
}

test.cpp: In function 'int main()':
test.cpp:3: error: no match for 'operator==' in '(Foo)10 == 10'
test.cpp:3: note: candidates are: operator==(int, int) <built-in>


The point of the change suggested in bug 3999 is that this looks good to be adopted in D too. Enumerated sequences in my opinion are less bug-prone if they are true distinct types.

--------------------

Note: despite in D unfortuntately constants and enumerated values share the same keyword, here I am not talking about constants like this one:

enum int foo = 10;

This foo is really of type int, it's not an enumeration, it's not a sequence of symbols of length 1 named foo. Semantically it is another thing (this is also why using the enum keyword for both things was the wrong choice).

Bye,
bearophile