enum
deadalnix
deadalnix at gmail.com
Sat Apr 12 00:25:34 PDT 2014
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.
More information about the Digitalmars-d
mailing list