No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/7/21 11:20 AM, Steven Schveighoffer wrote:
> If you mean we shouldn't support it (as an ambiguous case) in 
> *conversion* utilities (i.e. to/from string), then this makes some 
> sense. But it's also not straightforward. Sometimes you WANT to convert 
> from the enum to the base type. Sometimes you want to convert to the 
> enum name. Going backwards (string to enum), which one makes more sense? 
> It depends on context. It also doesn't help that a string enum 
> implicitly converts to a string. The language is going to circumvent any 
> policies Phobos has on that front.

Enums are poorly designed, but that's only a small part of the problem.

The bigger problem is the corruption of a noble principle. We wanted to 
be as generic as possible, and indeed in the beginning that seemed not 
only possible, but also easy. I don't think there's any other language 
or library supporting different character widths with this little 
aggravation.

Then this whole "be as generic as possible" became a slippery slope of 
inclusion. Allow enum strings. Allow alias this strings.

How about no.

User: "I have this enum string str and phobos won't consider it a 
string. Help!"

Another user: "Just use str.representation if you want to pass str 
around as a string."

User. "Cool."

Case closed.