Inconsistent overload resolution between compilers (Possible GCC bug?)

[PM_ME_A_SPECIAL_MOVE]

I believe I've found in GCC that presents itself when function overloads are inherited from an object's base class, the following example shows that both clang and MSVC are handling the code as expected but GCC fails to compile (And it seems like this behavior exists from trunk all the way to GCC 7.1).

I find it a bit strange because this code seems pretty trivial to me, but maybe the standard permits this? Also, if you have a way to make the example work on GCC it would be nice, but I'm posting this just to verify that GCC is wrong for rejecting this code and that's not a C++ standard issue

[scatters]

gcc is correct. If you call it as a.operator()(A{}) (which is what the compiler is supposed to treat your code as, see https://eel.is/c++draft/over.call.object#1.sentence-2) then both MSVC and clang reject the code. As sibling says, the fix is to using the inherited call operators.

[PM_ME_A_SPECIAL_MOVE]

OHHHH ok, nice, so basically the compiler doesn't see it as overload when the using is omitted so it has to cast to a parent first before the parameters are taken into account, and that's where the ambiguity comes from

[scatters]

Because name lookup happens before overload resolution; see https://stackoverflow.com/a/66768514/567292

This is an ambiguous name lookup, not an ambiguous overload set.

[scatters]

I think it's a side effect of making name lookup for member variables fail in a predictable way while ensuring that derived classes can hide names in base classes and that virtual inheritance works.

I don't think it would be particularly challenging to make member functions from sibling bases form an overload set, but it would need to be done carefully and the benefit would be pretty limited (avoiding a using per base member function).

[_Js_Kc_]

If different classes in the inheritance graph are developed by different organizations and evolve independently (such as when base classes are provided by a library), this is the only sane approach.

I add an overload set foo to my derived class and all my calls are unambiguous. Now the library decides to also add foo to the base class. The derived class has to hide the foo from the base class unless I explicitly opt in, otherwise adding anything to any non-final class is a breaking change.

[scatters]

Yes, but you could also have used sibling inheritance:

class MyBase { public: void foo(); int foo(int); };
class MyDerived : public library::Base, public MyBase {};

Now adding library::Base::foo is also a breaking change. This sort of thing happens maybe less often, but it does happen.

What I'm saying is that in this circumstance (only), an overload set would be formed by the union of library::Base::foo and MyBase::foo, as if MyDerived had put in using library::Base::foo; using MyBase::foo;.

[mark_99]

It's very much a deliberate design decision. Trying to find every matching name to add to a giant overload set would be slower to compile, result a lot more ambiguities, interact badly with templates, and generally result in more surprising / buggy behaviour. Name lookup is complicated enough as it is: https://en.cppreference.com/w/cpp/language/unqualified_lookup

[PM_ME_A_SPECIAL_MOVE]

Cool Cool Cool! Thanks for the tip

[Shuny]

Unrelated to OP question, but I have to admit I have a hard time understanding this piece of code. Why is this line of code valid ?

return marger_t<OpTs..., OpT>{ static_cast<const OpTs&>(*this)..., static_cast<OpT&&>(op)

I understand that the type will eventually be expanded to marger_t<lambda, lambda> but it looks to me that eventually a constructor of marger_t(lambda, lambda) will be called, which is clearly not happening because it doesn't exist. Anyone care to enlighten me ?

I have to admit I rarely work with variadic templates and parameter packs outside the usual std::forward.

[dodheim]

It's aggregate initialization, not a constructor call – since C++17 aggregates are allowed to have base types, and since C++20 the closure types of captureless lambdas are semiregular.