enum

[Steven Schveighoffer]

On Sat, 12 Apr 2014 03:25:34 -0400, deadalnix <deadalnix at gmail.com> wrote:

> 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 doesn't exist without a well-behaved enum. The fact that it  
was built upon a broken enum system is the exact problem. Without an enum  
that guarantees (without type subversion) that it can only be one of the  
prescribed values, final switch is broken. Of course it's fine as a  
concept, but it needs the guarantee. I'm trying to fix the guarantee, or  
at least add a mechanism for future programmers to provide the guarantee.

>> 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.

What is the logical conclusion that I am avoiding?

>> 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.

I'd not be against doing this, but we have to weigh the benefits against  
the code breakage. For cases where enum is NOT used in a final switch  
(like the UserId case), what are the benefits?

What I'm trying to do is solve the final switch without affecting code  
that doesn't care about final switch.

-Steve