"bearophile" <bearophileh...@lycos.com> wrote in message news:heiaea$1oc...@digitalmars.com... > Jason House: > >> IMHO, enum is a patchwork collection of features... manifest constants, >> enumerated lists, and bitmasks are all conflated into something rather >> ugly.< > > Manifest constants defined with enum look a little ugly, and I too don't > like it, but it's not even a syntax problem, it's a naming problem, so we > can survive with it. Do you have ideas for alternative design of manifest > constants? (LDC may even not need manifest constants at all, especially > when you use link-time optimization). > > The enumerated lists of D2 may enjoy to grow some built-in way to invert > them, and little more. > > Regarding bitmasks, I don't like how they are implemented in C#. D can do > better, while keeping things simple. > > Do you have ideas for a better design of those three things? (I don't want > heavy Java-like enums). > > Bye, > bearophile
One idea I've had is to keep the feature mainly as-is, but acknowledge the fact that *actual* enumerations are just a subset of what "enum" does and that these real enumerations are really just multiple manifest constants of a common underlying type put together inside a single namespace that acts as a new type. So instead of having a so-called "enumeration" feature that also does manifest constants, we should have the naming reflect the fact that it's really just a souped-up manifest constant feature. In other words, just like you implied - give it a better name... Too bad "const" is already taken. What would ideally be nice is to rename the current "const" to "readonly" (since that's what it *really* is anyway, the current "const" is nearly as poorly-named as the current "enum"), and then change "enum" to "const". Or take a page from Java and use the word "final" ("final x = 7; final Color {Red, Green}"), which is already a keyword in D anyway. Although all of that would still maintain the oddity that enum, or whatever it's called, sometimes creates a new type and sometimes doesn't. Another good idea is like yigal said, just improve the optimizer so that any immutables whose value is known at compile-time ends up effectively being treated as a manifest constant. Then rip out enum's "enum x = 7;" syntax and be done with it. Yigal also brought up another good point that I had also alluded to recently in a different thread: We could really use a better way to handle lists of enum values that are implemented with bitmasks instead of arrays (and we would still need to maintain the ability to control what bit patterns are used for each option, of course). Currently, doing that requires bypassing the type system to a certain extent. So that really should be improved. Maybe a fix for that could overlap with an improved union, or an improved bit-field concept, maybe involving something like the excellent bit (un)packing syntax in Erlang: http://www.erlang.org/documentation/doc-5.4.12/doc/programming_examples/bit_syntax.html