No we should not support enum types derived from strings

[Meta]

On Tuesday, 11 May 2021 at 16:44:03 UTC, Andrei Alexandrescu 
wrote:
>> Again with moving the goalposts.
>
> To clarify: you can't make up your own definitions as you go so 
> as to support the point you're making at the moment. You can't 
> go "oh, call it something else than a type, my point stays". 
> No. Your point doesn't stay.
>
> By the same token you can't make up your own definition of what 
> subtyping is and isn't. Value types and reference types are 
> well-trodden ground. You can't just claim new terminology and 
> then prove your own point by using it.

I apologize for injecting myself into this conversation, but with 
all due respect, what the hell are you talking about? Everything 
Deadalnix is saying makes perfect sense - it's basic type theory, 
and yet you're accusing him of moving goalposts and making up 
definitions, etc. The problem is that `isSomeString` doesn't 
respect the LSP and the template constraints on the relevant 
stdlib functions for enums are a hack to work around that. End of 
story. if `isSomeString` was defined sensibly, these template 
constraint hacks would not have to exist.

All the bluster about `popFront` on enum strings, etc. is 
completely irrelevant, and is a red herring anyway (as was 
already explained).

I'm sorry for being so blunt, but this conversation is painful to 
read.