No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/7/21 11:51 AM, Steven Schveighoffer wrote:
> On 5/7/21 11:30 AM, Andrei Alexandrescu wrote:
>> 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.
> 
> But an enum with base string type can be passed as a string. The PR in 
> question is working around a limitation of the Phobos trait that says 
> something derived from a string isn't really usable as a string (when it 
> is).

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...)

So enum strings break ISA/Liskov. Alias this also does due to an 
overwhelming number of errors in its design and implementation.

> The problem I see is, when phobos says something isn't true, when it 
> really is, causes no end of confusion (*cough* autodecoding)
> 
> static assert(!isSomeString!T);
> // yet...
> string s = someT;

This only shows that we have a baroque language that allows user-defined 
conversions from non-strings to strings. The code above is NO PROOF that 
T is supposed to be a string.

>> 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: "OK, but when should I use representation? I already pass it 
> around as a string and it works fine. Why can't phobos comprehend that, 
> when the language has no problems with it?"

"When you want a string".