No we should not support enum types derived from strings

[deadalnix]

On Wednesday, 12 May 2021 at 23:31:21 UTC, Paul Backus wrote:
> This *does* work as expected: https://run.dlang.io/is/Ru9phk
>
> The issue with `format` is that it takes an alias parameter, 
> not a value parameter--and the reason it does *that* is to 
> support string, wstring, and dstring with a single overload.

Yes, so we are getting at the root of this.

I know these thing work, this is why I stated that SomeEnumString 
is a subtype of string to begin with, it has all the properties. 
If that wasn't working, then I would have been mistaken when 
making such assertions.

It is working in the simple case, it is expected to work from the 
caller's standpoint due to the LSP, but it doesn't work in 
practice due to some obscure implementation detail that is of 
little concern to the user.

Pushing this on the user is not the way to go.

If the library writer desire to bundle string/dstring/wstring in 
the same implementation, this doesn't change the fact that it 
ought to work with subtypes. Choosing to break this is what 
"flies in the face of the LSP".

I would also like to see people think what make respecting the 
LSP challenging in such case, and see what can be done at a 
systemic level. It's kind of a bummer that the path of least 
resistance is to break the LSP when going for more genericity in 
another dimension.