Feature request: enum init shouldn't create a new enumeration

[Tommi]

On Sunday, 14 October 2012 at 19:40:17 UTC, Nick Sabalausky wrote:
> Yes, but it still has to be taken into account in things like 
> "final switch". You can't just pretend that nothing will ever
> have that value, because by making it the init value, you've
> *made* it an actual possible value, one that just happens to
> indicate "uninitialized".

*I* know that named enum variables can have whatever values; it's 
rather *you* and DMD who are pretending that enum variables can 
have only those values which are specifically enumerated.

You say that final switch should take into account an enum init 
value which can be used to represent an invalid value. I say that 
final switch shouldn't consider that (invalid) init value any 
different from all the other values that are invalid for that 
specific enum type, that is: all the values that are not 
speficied explicitly by the enumerations. And the way final 
switch should take all those invalid values into account, is by 
throwing an error when a final switch switches on a value not 
specifically defined by the enumerations.

Dmd also seems blinded into thinking that the specified 
enumerations are all that an enum variable can ever be, while in 
reality, it's very easy to write a bug that makes an enum 
variable have an invalid value. E.g:

enum MyEnum { first, second, third }

auto me = MyEnum.min;

while (me < MyEnum.max)
{
     // do something
     ++me;
}

switch (me) // this should throw
{
case MyEnum.first:  break;
case MyEnum.second: break;
case MyEnum.thrird: break;
}