No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/12/21 11:30 AM, deadalnix wrote:
> Last time I we had a discussion on the matter, it went in a loop that is 
> best summarized as this:
> enum E : int { A, B, C }
> 
> while (true) {
>    Me: A | B ought to be an int, not an E.
>    W&A: But you need it to be an enum, so that you can do things like 
> combining flags and stay. As in:
>      enum Mode { Read, Write }
>      openFile(file, Mode.Read | Mode.Write);
>    Me: Wl then, you can't have final switch, because you don't have the 
> guarantee it rely on.
>    W&A: final switch is very much needed, from X, Y Z reason.
> }

I know this is Walter's take, but please don't ascribe it to me as well. 
I could at the very best give a nod to practicality, but I very much 
think that typing binary "or" on enums as the enum is a kludge.

> This is extremely tiresome and kinda looks like the current discussion 
> (or another one would be the in contract needing to be statically bound, 
> where Timon and Myself had to fish for Bertrand Meyer because nothing 
> short of an argument from authority could do the trick).
> 
> So if we get nothing else out of that discussion, fixing enum so that 
> they don't go out of the allowed set of value would be nice. It's just 
> unfortunate that it takes literally 5 years+ to get to a point where 
> this is even acknowledged as being an issue.

This reach for credit here does not seem very well deserved.

> I hope we can somehow shorten that process, because it's not workable as 
> it is. You have people around like Timon and myself who have an eye for 
> this. It's free brainpower you are leaving not leveraging.

I will say what follows with the utmost respect. I think Timon is way 
better at these things (like in, incomparably better) than you and me 
combined. He most certainly is less skilled than you at other things, 
but as far as PL theory in this group goes, he and Paul are the only 
game in town.