Daniel Gibson:
> Then there still is the consistency-issue (anon. enums are treated
> differently then named enums).
Look at this:Se
enum int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...
Color is a sequence of symbols, Red, Green and Blue, named Color. When you
write your program often all you need to know is if color is Red or Green, and
you don't care much how the compiler represents those symbols.
The n is a compile-time constant value. It's not a sequence of something.
Now, just for fun, replace the first enum with something as:
ctconst int n = 10;
enum Color { Red, Green, Blue }
Color color;
if (color == Color.Red) { ...
ctconst is a fictional keyword that denotes compile-time constants. Now you are
probably able to see that there is no correlation between the n and Color.
In D they are using the same keyword by accident, probably because Walter
thinks that saving a keyword is more important than keeping the semantics tidy.
So today you are probably struck with using "enum" to define compile-time
constants.
The C++0x design group has not introduced the "enum class" for fun, their
strong typing nature is useful to make the code less bug-prone. See:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1719.pdf
See for example "Problem 1: Implicit conversion to an integer".
Bye,
bearophile
