enum

[deadalnix]

On Saturday, 12 April 2014 at 03:07:39 UTC, Steven Schveighoffer 
wrote:
> I don't really understand this statement. The problem I'm 
> trying to solve is that final switch doesn't do what it's 
> supposed to do.
>

final switch is a fine construct. The fact that it can be fed 
garbage is the problem.

It can be fed garbage because enum to not provide any guarantee 
whatsoever. You are trying to solve a political problem because 
it appear that Walter is not gonna admit that he conflated 2 
semantic in one thing, and achieve to make it useless for both.

> final switch is fundamentally broken. It is supposed to be an 
> input condition to final switch that the value MUST be one of 
> the enum values. By allowing arbitrary math on enums, this is 
> not the case, even in @safe code.
>

You are arguing that final switch is broken, but your argument 
show that enums fail to provide any guarantee. You are avoiding 
the logical conclusion.

> In any case, it doesn't solve all enum problems, just that one. 
> Will it break code? Code that is written correctly, it will 
> break trivially (just add final to the enum declaration). Code 
> that is not written correctly, you will either have to use 
> normal switch, or fix the code.
>

The most basic, fundamental building block that is needed is a 
type with retained values. Literally every single other use case 
presented here can be built on top of this as library.

Additionally, this is also the only use case where compiler can 
take advantage of the knowledge it has for other things 
(optimization purpose, or additional feature like final switch).

There is no point in introducing additional core language 
feature, simply sanitize what exists and extends library support 
for uses cases discussed in this thread.