Non-enum manifest constants: Pie in the sky?

[Nick Sabalausky]

"bearophile" <bearophileHUGS at lycos.com> wrote in message 
news:heiaea$1ocp$1 at 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