https://issues.dlang.org/show_bug.cgi?id=23377

Paul Backus <snarwin+bugzilla@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |snarwin+bugzilla@gmail.com

--- Comment #1 from Paul Backus <snarwin+bugzilla@gmail.com> ---
Simplified example:

---
void main()
{
    Derived d;
    A a;
    d.fun(a);
}

struct A {}
struct B {}
struct C {}

class Base
{
    void fun(A a) {}
    void fun(C c) {}
}

class Derived : Base
{
    // if you comment this it will call Base.fun(A)
    void fun(B b) {}
}
---

I think what's happening here is that Base.fun and Derived.fun are in separate overload sets, and the derived-class overload set shadows the base-class one. Examining the overload sets with reflection appears to support this hypothesis:

---
struct A {}
struct B {}
struct C {}

class Base
{
    void fun(A a) {}
    void fun(C c) {}
}

class Derived1 : Base
{
    // if you comment this it will call Base.fun(A)
    void fun(B b) {}
}

// prints: tuple(fun)
pragma(msg, __traits(getOverloads, Derived1, "fun"));

class Derived2 : Base {}

// prints tuple(fun, fun)
pragma(msg, __traits(getOverloads, Derived2, "fun"));
---

--

https://issues.dlang.org/show_bug.cgi?id=23377

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |razvan.nitu1305@gmail.com
           Severity|normal                      |enhancement

--- Comment #2 from RazvanN <razvan.nitu1305@gmail.com> ---
This is intended behavior. For more information check [1]. Long story short, the current mechanism is in place to prevent hijacking. I guess an argument can be made that in this case neither A nor C are implicitly convertible to B, but to me this just seems like adding special cases when the alternative would be to simply use an alias to introduce fun(B) in the same overload set as the other fun methods.

I am inclined to close this as a WONTFIX. Either way, this is not a bug, but an enhancement request by the current language rules.

[1] https://dlang.org/articles/hijack.html#derived-class-members

--

https://issues.dlang.org/show_bug.cgi?id=23377

--- Comment #3 from Luís Ferreira <contact@lsferreira.net> ---
I didn't know that this was intentional, tbh.

It makes some sense, given the rationale and given that there's a clean alternative to behave correctly, although, I think this should be more explicit on the language documentation/spec, then, at least, the way to do it, with an example using an alias.

--

https://issues.dlang.org/show_bug.cgi?id=23377

Nick Treleaven <nick@geany.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nick@geany.org

--- Comment #4 from Nick Treleaven <nick@geany.org> ---
(In reply to Luís Ferreira from comment #3)
> although, I think this should be more
> explicit on the language documentation/spec, then, at least, the way to do
> it, with an example using an alias.

It is in the spec: https://dlang.org/spec/function.html#function-inheritance

However, it would be easier to find if the whole virtual functions section was moved to the class page.

--

https://issues.dlang.org/show_bug.cgi?id=23377

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--

https://issues.dlang.org/show_bug.cgi?id=23377

--- Comment #5 from Nick Treleaven <nick@geany.org> ---
I have filed issue 23384 so the compiler mentions the base method is hidden.

--