No we should not support enum types derived from strings
Steven Schveighoffer
schveiguy at gmail.com
Fri May 7 17:05:08 UTC 2021
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
More information about the Digitalmars-d
mailing list