No we should not support enum types derived from strings

[Steven Schveighoffer]

On 5/7/21 12:43 PM, Andrei Alexandrescu wrote:
> On 5/7/21 11:51 AM, Steven Schveighoffer wrote:
>> On 5/7/21 11:30 AM, Andrei Alexandrescu wrote:
>>> 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".
> 

Sorry, let's jump out of the fake dialog here for a second.

The problem I have is, you have a function like:

foo(T)(T s) if (isSomeString!T)

The *intention* here is that, I want to NOT have to write:

foo(string s) { impl }
foo(wstring s) { impl }
foo(dstring s) { impl }
... // etc with const, mutable

BUT, if I have an enum that converts to a string, then if I actually DID 
write all those, then it would compile. However, the template version 
does not. This is the confusion that a user and library author has.

I think the problem here is that the language doesn't give you a good 
way to express that. So we rely on template constraints that both can't 
exactly express that intention, and where the approximations create 
various template instantiations that cause strange problems (i.e. if you 
accept an enum that converts to string, it's still an enum inside the 
template). Whereas the language

I'm not suggesting any specific changes here, but I recognize there is a 
disconnect from what we *want* to express, and what the language provides.

-Steve