Non-enum manifest constants: Pie in the sky?

bearophile bearophileHUGS at lycos.com
Wed Nov 25 04:28:27 PST 2009


Nick Sabalausky:

> 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".

I like something like that. There's another couple of proposals. Let's see if Walter is willing to improve those names.


> 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.

One not written rule of D design seems to be that it must require a simple and low-tech compiler. That's the only explanation I see for some of the D design decisions that look silly if you think about having a good compiler under 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.

This problem may be fixed as bitfields, with a "good enough" mixin added to Phobos2 to define a bitmask. Anyone willing to write it?

Bye,
bearophile



More information about the Digitalmars-d mailing list