On Sat, 12 Apr 2014 03:25:34 -0400, deadalnix <[email protected]> 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
