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