[Issue 8146] Potentially ambiguous overloaded call

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=8146



--- Comment #1 from Kenji Hara <k.hara.pg at gmail.com> 2012-05-24 22:42:16 PDT ---
(In reply to comment #0)
> This is just a potential enhancement request. It's not an enhancement request
> because I am not sure about it.
> 
> A thread started by Andrej Mitrovic on D.learn:
> http://forum.dlang.org/thread/mailman.1043.1337863952.24740.digitalmars-d-learn@puremagic.com
> 
> In dmd 2.060alpha this code compiles and doesn't assert at run-time, so it
> calls the second overload:
> 
> 
> struct Foo {}
> void test(void* test) { assert(0); }
> void test(Foo* test) {}
> void main() {
>     test(null);
> }
> 
> 
> As Andrej comments, shouldn't this be considered an ambiguous call, and refused
> at compile time?

I think, no.

First, test(Foo*) is specialized than test(void*), because Foo* is convertible
to void*, but opposite isn't.

Next, a null literal has the typeof(null) and it is *most specialized type* of
all reference types. Then typeof(null) is a specialized type than Foo*.

So, with the call 'test(null)', overload resolution will select more
specialized test(Foo*) than test(void*).

Following is a similar case by the class hierarchy.

class B{}      // like void*
class C : B{}  // like Foo*
class D : C{}  // like typeof(null)
void foo(B o){}
void foo(C o){}
void main() {
    foo(new D); // calls foo(C)
}

As far as I know, this rule is same as C++.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------