Comment #0 by monkeyworks12 — 2015-02-16T08:59:52Z
This problem appears only if one of the parameters is an
interface. Without it or using any other type as a second
parameter instead of the interface, it compiles. Also it compiles
if the passed interface is null. The example below uses
short/ushort, but there is the same behaviour for any combination
of integral types of the same bitsize (byte/ubyte/char,
ushort/short/wchar, int/uint/dchar, long/ulong)
D 2.066.1
interface I {}
class C: I {}
void func(ushort s, I i)
{
writeln("ushort overload");
}
void func(short s, I i)
{
writeln("short overload");
}
void call(short s)
{
C c = new C();
I d = new C();
func(s, c); // ---- ERROR ---- see below
//but these are ok
func(s, cast(I)c) //ok
func(s, d) //ok
func(s, null) //ok
}
main.func called with argument types (short, C) matches both:
main.func(short s, I i)
main.func(ushort s, I i)
Comment #1 by yebblies — 2015-03-25T12:26:15Z
I'm not really sure if this is a bug, or just an unpleasant side effect of the way overloading is worked out.
IIRC the worst conversion out of all the args is taken as the match level for each function, and for both of those overloads the C -> I conversion is the worst, so they have the same match level and are ambiguous. It might be possible to tweak the match levels to fix this, I don't know.
There are probably other similar cases with other conversions that have the same match level as C -> I.
Comment #2 by robert.schadek — 2024-12-13T18:40:31Z