No we should not support enum types derived from strings

[Andrei Alexandrescu]

On 5/11/21 12:26 PM, deadalnix wrote:
> I however would like to remind where this whole thing starts from:
> 
> format!SomeEnumString(...) is expected to work for users.

Reasonable, though I should add that it's a decision made by the author 
of the format() API.

> Not that SomeEnumString is a full fledged range or anything, simply that 
> you can pass is down to phobos, or anything else for that matter, in 
> place where a string is expected.

Reasonable, though again a matter of API definition. Would you expect 
this to work?

float sin(float x);
double sin(double x);
real sin(real x);
...
auto x = sin(1);

Shouldn't that work? Not that int is a full fledged floating point 
number or anything, simply that you can pass it down to phobos, or 
anything else for that matter, in place where a floating point number is 
expected.

Oh, but wait, it's the templates. Great.

T sin(T)(T x) if (isFloatingPoint!T);
...
auto x = sin(1);

Shouldn't that work? Not that int is a full fledged floating point 
number or anything, simply that you can pass it down to phobos, or 
anything else for that matter, in place where a floating point number is 
expected.

Well an argument can be made that it should work, or the API designer 
can wisely choose to NOT yield true from isFloatingPoint!int.

And if we explore this madness further, we get to an enormity just as 
awful as StringTypeOf:

template FloatingPointTypeOf(T) {
     static if (isIntegral!T) {
         alias FloatingPointTypeOf = T;
     } else ...
}

And then whenever we need a floating point type we use 
is(FloatingPointTypeOf!T) like a bunch of dimwits.

What use case does that helps? Who is helped by that? Someone who can't 
bring themselves to convert whatever they have to double prior to using 
the standard library.

Arguably not a good design.