Non-enum manifest constants: Pie in the sky?

[yigal chripun]

bearophile Wrote:

> 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

Manifest constants reflect a toolchain problem and *not* a naming problem. They exist only because the linker isn't smart enough to optimize immutable variables. LLVM should already have this implemented.

regarding Java style enumarations, I disagree that they are too heavy. They are a *much* better design than the C/D/.. design.  I think the C style use of enums to implement bit masks is the problem and not the enum itself. 

there are two better designs IMO:
a) low level where you need manual control of the bit patterns - use ubyte/etc directly is more explicit andf therfore better. 
b) you don't care about the bits themselves and only want to implement OptionA | OptionB efficiently - bit patterns should *not* be exposed and should be encapsulated by a type. Java has a enumSet (I don't remember the exact name) that handles that efficently for you. 

either way, you shouldn't ever provide an interface for Option flags where the underlining implementation - the bit values are exposed to the user.