class S {}
class A:S {}
class B:S {}

mixin template vmix(T)
{
    void visit(T t) {}
}

class Visitor
{
    void visit(S s) {}
    mixin vmix!A;
    mixin vmix!B;
}

class AnotherVisitor: Visitor
{
    override void visit(A a) {}
}

This will result in error when I try to override mixin generated visit(A) in AnotherVisitor.

If A doesn't inherit S, the override in AnotherVisitor works like a charm.

Bug or feature? Is there any workaround?

On Friday, 3 December 2021 at 10:42:37 UTC, Rumbu wrote:

The error message explains what to do :)

On Friday, 3 December 2021 at 10:57:34 UTC, Stanislav Blinov wrote:

Yes, I know, but in fact the compiler wrongly assumes that visit(A) is hiding visit(S). visit(A) is just an overload, it has a different signature than visit(S), theoretically the compiler must mangle it using a different name.

Finally I solved it by "finalizing" visit(S), so it's not taken into overrides set.

class Visitor
{    
     final void visit(S s) {}
     //...
}

On 12/7/21 7:43 AM, Rumbu wrote:

It doesn't have to do with mangling. It has to do with implicit conversions.

A more classic example would be:

class A
{
   void foo(long i) {}
   void foo(int i) {}
}

class B : A
{
   override void foo(long i) {}
}

This hides A.foo(int), because B.foo(int) will call the long overload instead, when you might expect it to call the base class int overload.

But I agree with you that this seems like a bug -- the anti-hidden overload error is supposed to complain when you have an implicitly convertible parameter. In this case, you aren't hiding visit(S) because visit(A) would not accept an S.

The spec's explanation is pretty poor (and has invalid demo code to boot).

-Steve

On Tuesday, 7 December 2021 at 12:43:40 UTC, Rumbu wrote:

Feature. It even has a name: "overload set". It keeps you from accidentally calling a function you had no idea existed, for example because of a name clash.

Yes, the error message is very clear.

On 12/7/21 1:03 PM, Q. Schroll wrote:

Not in this case. See this demonstration (I removed irrelevant pieces):

class S {}
class A:S {}

class Visitor
{
    void visit(S s) {}
    void visit(A a) {}
}

class Derived : Visitor
{
}

void main()
{
   auto v = new Derived;
   v.visit(A.init); // calls visit(A)
   v.visit(S.init); // calls visit(S)
}

Now, let's add a supposed "hiding" function:

class Derived : Visitor
{
   override void visit(A a) {}
}

Now, we have these 2 lines:

v.visit(A.init); // works, calls visit(A), just like before
v.visit(S.init); // fails to compile, no overload for S.

Where is the hidden function? If you are thinking that just because it's not brought forth in the overload set, that's not important. Change the two visit parameters to string and int, and it compiles just fine:

class Visitor
{
    void visit(string s) {}
    void visit(int a) {}
}

class Derived : Visitor
{
    override void visit(int a) {} // no problem, even though we don't cover the string case
}

NOW, if you did instead:

class Derived : Visitor
{
   override void visit(S s) {}
}

Now there is a hidden function, because visit(A.init) is going to call the derivative visit(S), whereas before it would call Visitor.visit(A).

But that isn't this case.

The spec says:

"It is illegal if, through implicit conversions to the base class, those other functions do get called."

The spec does not seem to cover this case, and the rules it states are not exactly what the compiler currently implements. I'm not sure where the bug is -- spec or implementation -- but there is a disagreement for sure.

It's telling that making the S-accepting function final will fix the problem.

-Steve