No we should not support enum types derived from strings

[deadalnix]

On Tuesday, 11 May 2021 at 16:57:13 UTC, Andrei Alexandrescu 
wrote:
> 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.
>


It's debatable. There are many languages out there where it 
doesn't.

I think your case here is disingenuous, because an int is not a 
special kind of float. We are explicitly outside of the scope of 
the argument being made to begin with. Whatever conclusion we 
reach using int and float would have no bearing on what should 
happen for string and SomeEnumString.

However, in D, it is possible to do:

enum SomeEnumInt : int;

This is for instance used in std.encoding. UI'm not sure if this 
works with float or not, but assuming that it does, then this 
absolutely and unambiguously work:

enum SomeEnumFloat : float;
SomeEnumFloat f = ...;
auto x = sin(f);

Here, x would have type float, based on `float sin(float x)`.

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

An argument could be made, however, this is not the argument I am 
making, so I don't really see the point of bringing this up.

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

This is indeed not a good design, but also isn't really required 
if the places requiring a float can consistently accept 
SomeEnumFloat, because in this case, it turtles transparently all 
the way down.