No we should not support enum types derived from strings

[Jonathan M Davis]

On Tuesday, May 11, 2021 12:37:20 PM MDT Meta via Digitalmars-d wrote:
> 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.

Having isSomeString accept types that implicitly converted to string would
be a disaster. Templates do not operate on implict conversions - or even on
subtypes. They operate on the exact type they're given. You can, of course,
write a template constraint which checks for implicit conversions, but you
still don't get the implicit conversion when the template is instantiated.
You get the original type. This has a number of implications, but in
general, it leads to bugs if templates check for implicit conversions
instead of exact types. In particular, any templated function which checks
for an implicit conversion then needs to force the implicit conversion, or
it will likely not work properly - be it because you get compilation errors,
or because the original type compiles with the same code but does not behave
the same way as the type from the implicit conversion which was not actually
made.

In fact, IIRC, at one point, isSomeString _did_ work with enums, and we
fixed it so that it didn't, because it was causing problems. Also, IIRC, it
was my fault that it was ever made to work with enums, and I very much
regret that.

In general, implicit conversions have no business in template constraints.
Obviously, there are exceptions to that, but in general, there will be fewer
bugs if the conversions are done explicitly by the code instantiating the
template. The reason that it's done in Phobos as much as it is is primarily
because of code that was originally not generic which was later templatized
(often because it took string and was changed to work on multiple string
types or to work on general ranges of characters). And in most cases where
we've tried to templatize functions without breaking code, we've had
problems because of the implicit conversions that worked before.
std.traits.isConvertibleToString is one such abomination which came out of
that (its use usually results in code that slices local variables and
escapes them, which is really bad). IIRC, that was done by Walter, and if
he's making mistakes like that with regards to implicit conversions and
templated code, what do you think the average D programmer is doing?

The main reason for bringing up popFront and enums is to show that that
enums with a base type of string are not actually strings, and treating them
as if they were causes serious problems. There are of course places where
that sub-typing results in implicit conversions, but templates do not work
that way, and trying to force it is very problematic. The proliferation of
template constraint and static if complexity that Andrei is complaining
about with regards to stuff like format is the result of that, and it's the
kind of code that's very hard to get right. Simply not trying to support
those implicit conversions with templated functions _significantly_ reduces
the complexity of such code with the only cost being that the code
instantiating the template will have to use cast(string) on the enum value.

- Jonathan M Davis