No we should not support enum types derived from strings

[deadalnix]

On Friday, 7 May 2021 at 16:43:20 UTC, Andrei Alexandrescu wrote:
> Well you see here is the problem. An enum with base string can 
> be coerced to a string, but is not a true subtype of string. 
> This came to a head with ranges, too - you can pop off the head 
> of a string still have a string, but if you pop off the head of 
> an enum string you get some enum value that is not present in 
> the set of enum values. Concatenation has similar problems, 
> e.g. s ~ s for enum strings yields string, not an enum string. 
> (Weirdly s ~= s works...)
>

Popping the head out of an enum value ought to be a string, not 
that enum's value. I don't really see where the problem is here, 
this is subtyping 101.

I raised a few times int he past that there were unsound 
operations performed in the past (as in "Weirdly s ~= s 
works...") but I don't think turning compiler bugs into standard 
library policies is going to lead to better tomorrows.