No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/7/21 10:16 AM, Paul Backus wrote:
> On Friday, 7 May 2021 at 12:06:43 UTC, deadalnix wrote:
>> On Friday, 7 May 2021 at 11:55:53 UTC, Andrei Alexandrescu wrote:
>>> Heavy toll on the infra for a very niche use case with trivial 
>>> workarounds on the user side.
>>
>> It seems like the toll comes from isSomeString to return false for 
>> these nums, no? What is the root cause of this not working?
>>
>> It doesn't seems like this should be a special case anywhere and just 
>> work.
> 
> "Is a string type" and "is implicitly convertible to a string type" are 
> not the same thing.

Yah. It's really been a string (heh!) of suboptimal decisions.

1. We wanted strings to be synonym to built-in slices of char. "Users 
should not need to define their own string type!" This has been D's 
billion dollars mistake.

2. Representing strings are char[] meant GC is a must and also there's 
long-distance coupling between callers and callees whenever strings are 
passed about: a callee may modify characters in the caller's string. 
Such changes could have been absolutely trivially disallowed with a 
user-defined string type, but see (1) and did I mention D's billion 
dollars mistake?

3. So yours truly (shudder) came up with the idea of doing strings as 
immutable(char)[] so that people can pass strings around, no coupling, 
no problem. GC is still a must. That satisfies (1) but bought us into 
the entire qualifiers business, which, any way I look at it, did not 
produce enough dividends compared to the effort put into it and the 
massive complications added to the language. (Aside: inout is the 
weirdest thing. How could we ever think that that was a good idea.)

4. When doing generic string functions for phobos, it made sense to 
support... oh wait a second we have so many string types. char[], 
wchar[], dchar[], each in triplicate because of const and immutable. So 
right of the bat we decided to support 9 string types. That was another 
mistake because nobody cares about wchar and dchar. Anyway, that's how 
isSomeChar and isSomeString were born.

5. Then came the question of ranges that have one of those 9 character 
types as elements... those should be supported too, no? IIRC at least a 
subset of phobos supports that stuff.

6. Then of course someone figured, wait a second, what about enums 
derived from strings and user-defined types that have an alias this as 
string... those deserve attention too, right? And right here we had 
descended into madness.


Compare all that with:

0. We put a String type in the standard library. It uses UTF8 inside and 
supports iteration by either bytes, UTF8, UTF16, or UTF32. It manages 
its own memory so no need for the GC. It disallows remote coupling 
across callers/callees. Case closed.