Contradictory justification for status quo

[Jonathan M Davis via Digitalmars-d]

On Wednesday, February 25, 2015 21:06:53 deadalnix via Digitalmars-d wrote:
> Here is something I've noticed going on various time, recently in
> the memory management threads, but as to avoid an already heated
> debate, I'll use enum types as an example.
>
> We have a problem with the way enums are defined. If you have :
>
> enum E { A, B, C }
> E e;
>
> We have (1)
> final switch(e) with(E) {
>      case A:
>          // ...
>      case B:
>          // ...
>      case C:
>          // ...
> }
>
> But also have (2):
> typeof(E.A | E.B) == E
>
> When raising this, the discussion goes as follow
>   - "If you have (1), we can't have (2), as break guarantee (1)
> rely on."
>   - "(2) is usefull. For instance UserID or Color"
>   - "Then let's get rid of (1)"
>   - "(1) is useful, for instance to achieve X or Y"
>   - "Let's create a new type in the language, (1) would be enum
> and (2) would be this new type"
>   - "It adds too much complexity in the language"
>
> This very conversation went on in a very lengthy thread a while
> ago (note, for SDC, I just dropped (2), typeof(E.A | E.B) == int
> and I consider it a closed issue).
>
> It can go forever, as all reason given for every concern raised
> is valid. Yes, adding a new type is probably too much for the
> benefit, yes (1) and (2) are useful in various scenarios. And, by
> refusing to take a step back look at the problem as a whole, we
> can turn around forever and never conclude anything, benefiting
> only the status quo.
>
> I've seen this attitude going on on various topics. This is the
> surest and fastest way to end up with C++ without the C source
> compatibility. I'd like that we just stop this attitude.

Personally, I think that the status quo with enums is horrible and that no
operation should be legal on them which is not guaranteed to result in a
valid enum value and that if you want to create a new type that can have
values other than those enumerated, you create a struct with some predefined
static values and don't use enums at all, but others disagree vehemently
(Andrei included). However, as it stands - as you point out - final switch
is completely broken, which is not a subjective issue at all but rather
quite an objective one. The solution that was proposed (by Andrei I think)
the last time that I was in a discussion on that was to introduce the
concept of "final enums" so that if you do something like

final enum E { A, B, C }

it's then the case that no operation on E is legal unless it's guaranteed to
result in an E (with casting being the way out when required, of course),
and then we would move towards making final switch illegal on normal enums.
I was going to create a DIP for it but forgot. I still think that it's
something that needs to be resolved though, since otherwise, enums are ugly
to work with (subjective though that may be), and final switch is broken.

- Jonathan M Davis