enum

[Meta]

On Saturday, 12 April 2014 at 13:33:07 UTC, Jonathan M Davis 
wrote:
> On further reflection, I think that having enum and final enum 
> would make
> sense as long as enum were changed so that it introduced an 
> alias rather than
> a new type. A new type just doesn't make sense if you're not 
> listing all the
> values - especially because the few protections that the 
> compiler has against
> giving an enum a non-enumerated value just get in the way of 
> that use case -
> whereas if the enum _is_ intended to enumerate all its values, 
> it makes sense
> that it would introduce a new type that was protected against 
> having it set to
> non-enumerated values. So,
>
> enum UserID : ulong { nobody, expired = ulong.max }
>
> would then introduce an alias UserID for ulong as well as 
> namespace the
> constants nobody and expired, but there would be no new type 
> introduced, so it
> would not protect against being assigned non-enumerated values, 
> and it would
> not affect overloading. It also wouldn't work with final switch.
>
> final enum State { initial, waiting, running, done }
>
> would then be the same as
>
> enum State { initial, waiting, running, done }
>
> is now except that the compiler would actually guarantee that 
> no variable of
> type State could have a non-enumerated value unless a cast was 
> used (so any
> operation which wasn't guaranteed to result in an enumerated 
> value would
> result in a value of the base type rather than the enum type). 
> And of course,
> it would then work properly with final switch, because it 
> couldn't have a non-
> enumerated value unless you forced it with a cast.
>
> With that separation, we can then separate out the enums which 
> are really
> enumerations and those which are really just a group of related 
> constants. But
> I think that the key thing is that introducing a new type 
> really doesn't make
> sense if it's just a group of related constants. Introducing an 
> alias is fine
> - but a new type just doesn't make sense IMHO.
>
> For better or worse, if we went this route, we'd end up with 
> something closer
> to C++11's enums and enum classes, though unlike enum classes, 
> our final enum
> would implicitly convert to its base type, and operations on it 
> which weren't
> guaranteed to result in a valid enum value would result in the 
> base type,
> whereas it's my understanding that you have to overload 
> operators to get any
> of that working at all with enum classes.
>
> - Jonathan M Davis

If we were really serious about changing enums, I'd say scrap the 
whole thing and take a look at how Rust does them, and change the 
semantics of final switch to allow for pattern matching, while 
leaving switch around as a legacy C construct and discouraging 
its use in regular code.