No we should not support enum types derived from strings

[Paul Backus]

On Wednesday, 12 May 2021 at 23:42:11 UTC, deadalnix wrote:
> 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".

Well, no, it doesn't--because, again, the LSP doesn't apply here 
in the first place, and never has. Flies in the face of user 
expectations, perhaps--though even then, if the user looks at the 
documentation and see `isSomeString!(typeof(fmt))`, is it really 
reasonable for them to expect that a non-string type will be 
accepted?

I think it's a reasonable API design decision to support any type 
that implicitly converts to a string type, but it's not the 
*only* reasonable decision, and we ought to acknowledge the costs 
as well as the benefits.

Personally, my inclination is to err on the side of making the 
standard library a little more complex so that user code can be 
simpler, but Andrei makes a convincing argument that this 
tendency has gotten us into trouble before [1]. How do we decide 
where to draw the line? There has to be some principle here 
beyond just "users expect it" and "respect the LSP."

[1] https://forum.dlang.org/thread/q6plhj$1l9$1@digitalmars.com

> 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.

IMO this is all downstream of D's choice to use untyped templates 
as opposed to typed generics (a tradeoff that goes all the way 
back to Lisp vs. ML). It's a fun thought experiment to imagine a 
version of D that took the other path, but there's not much we 
can do about it now.