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.
