There's a simple solution: don't use that failure of a language
construct called enum, and write your own one. You simply can do
something Java-style, where enums basically are just normal classes
generated by the compiler frontend. In D, you can use structs, and
string mixins can generate the appropriate fields. Something like:
struct YourEnum(char[] fields) {
private int value;
mixin(generatefields());
static char[] generatefields() { return YOURMAGICHERE(fields); }
}
Enum fields are static and of the type YourEnum. e.g.
YourEnum("FOO,BAR") would add these members to the struct:
const YourEnum FOO = YourEnum(0);
const YourEnum BAR = YourEnum(1);
These are generated by the CTFE function generatefields().
As long as the value field is hidden, you have enums that are even more
typesafe than the good old Pascal counterparts. Oh, and you can easily
add code to convert strings to enum values, too.
Walter can delete all that buggy enum code from his compiler and from
the language specification.
struct MyEnum {
enum FOO = 0;
enum BAR = 1;
}
Gah, this abuse of the enum keyword is really outright disgusting.
I also find it ironic how Walter tries to keep D C compatible (that is,
C code compiled by dmd either runs correctly, or compilation fails),
while such differences between D1 and D2 seem to be OK. (Examples:
const, memory allocating closures, overloading rules)
