enum

[Dominikus Dittes Scherkl]

On Friday, 11 April 2014 at 19:53:14 UTC, deadalnix wrote:
> On Friday, 11 April 2014 at 12:21:59 UTC, Steven Schveighoffer 
> wrote:
>> final enum name { ... }
> I unerstand what you are trying to do here. You are solving a 
> political problem, with a solution that is inferior (but won't 
> require anyone to be proven wrong, so that have greater chance 
> to be accepted).
Why is it inferior?
Both kinds of enums are in use, and I can not decide which type 
is more "obvious" or "most common" (e.g. I like flag-arrays a lot 
- and in D it's usual to define them as enums so do I).
> The problem is that is increase language complexity
Yes, a new type increases the complexity. But what would be the 
alternative? Removing enums? No, they are much too useful. But 
they come in two totaly different kinds, so having two distinct 
types is very sensible, I think. It is well worth the small 
increase in complexity (hey, with the "trick" of using final enum 
we didn't even need a new keyword and the difference is easy to 
remember).

> plus make the most common use case of enum nit the most direct, 
> obvious one. It is going to break every single piece of code 
> that use final switch.
I think this will be a 2-step implementation. First one should 
get a warning that non-final enum will be deprecated from use in 
final switch and second the warning will be turned into an error.
In fact I think its a good idea to review every such warning if 
really final enum should be used or if it would be better to use 
non-final switch.

> And the default behavior of enum still remain a useless 3 
> headed monster,
Why? It should now only be used for incomplete enumerations and 
can no more be mis-used in final switches, so one head is off. 
About the remaining two: if you like to use arithmetics on your 
enums is up to you. If you don't like it, don't use it.
I use flag-arrays often and wouldn't like to define a complicated 
structure for each of them.