[Issue 19399] Different Conversion Rules for Same Value and Type -- Enum
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Fri Feb 15 14:11:20 UTC 2019
https://issues.dlang.org/show_bug.cgi?id=19399
Simen Kjaeraas <simen.kjaras at gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |simen.kjaras at gmail.com
--- Comment #5 from Simen Kjaeraas <simen.kjaras at gmail.com> ---
I started out thinking this was not a bug, since enum values are basically
inserted verbatim into the code. And indeed, this is exactly what should happen
in cases like this:
int fun(ubyte) { return 0; }
int fun(ulong) { return 1; }
enum M = 10;
// Exactly equivalent to foo(10); - will call the ubyte overload.
static assert(fun(M) == 0);
However, this intuition breaks down when the enum has a specified type:
enum ulong N = 10;
// Will always call the ulong overload.
static assert(fun(N) == 1);
Both of these cases are working correctly. The error is with enums with curly
brackets. If no type is specified for the enum, the behavior is correct:
enum O {
O = 10
}
// Exactly equivalent to foo(10); - will call the ubyte overload.
static assert(fun(O.O) == 0);
However, when the type is explicitly specified, the error occurs:
enum P : ulong {
P = 10
}
// Should call the ulong overload, but type information is discarded and the
ubyte overload is called instead. This assert will fail.
static assert(fun(P.P) == 1);
VRP, as pointed out by Simon in comment 1, is what causes the conversions, even
in the array examples in comment 4. Simply put, the compiler prefers to
interpret a number as an int, but will try other types if they are a better
fit. The only issue is that VRP is used when a type is explicitly specified for
an enum with braces.
--
More information about the Digitalmars-d-bugs
mailing list