No we should not support enum types derived from strings

[Adam D. Ruppe]

On Saturday, 8 May 2021 at 19:06:48 UTC, guai wrote:
> I ment this [combining 
> characters](https://en.wikipedia.org/wiki/Combining_character). 
> they are language-specific, but most of the time the string 
> does not contain any clue which language is it.

The thing is making the range be of dchars doesn't help with this.

This kind of thinking is why Phobos does the autodecoding thing 
it does now, converting utf-8 to a range of dchar as it sees 
it... but those combining characters are still (or rather can be) 
two separate dchars!

So right now Phobos does something that seems useful... but 
actually isn't. All of the bad, none of the good.

BTW I also like to point out that Ascii actually has a lot of the 
same mysteries we ascribe to unicode. Like variable width chars: 
\t is an ascii char. Zero width char, ascii has \0 and \a. 
Negative width char? Is \b one? idk.

But there's still a lot of times you can treat it as bytes and 
get away with it.

This is why I'm not sold on Andrei's new String idea myself. I 
totally agree making char[] a range of dchars is a bad idea. But 
I think the only right thing to do is to expose what it actually 
is and then both educate and empower the user to do what they 
need themselves.