No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/7/21 1:05 PM, Steven Schveighoffer wrote:
> 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.

Of course. I understand that very well. But that's a minor confusion and 
inconvenience; people understand very well that e.g. this won't work:

void foo(float);
void foo(double);
void main() { foo(1); }

The reason is slightly different but the point is the same: 
convertibility has its subtleties and programming languages comprehend 
small surprises.

Supporting enum strings and alias this at the huge cost we incur now is 
definitely over two standard deviations away from what's reasonable.

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

That I am on board with.