[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