use of overloaded `operator==` is ambiguous (with reversed parameter order)

[dermojo]

Bugzilla Link	46508
Version	10.0
OS	Linux
CC	@rbock,@zygoloid

Extended Description

Hi,

The following code is a very reduced example from a template expression library:

  class Foo {};

  class X {
  public:
      template <typename T>
      constexpr Foo operator==(const T&) const 
      {
        return Foo{};
      }
  };

  class A : public X {};
  class B : public X {};

  int main() {
    Foo f = A{} == B{};
    return 0;
  }

It fails to compile with C++20:

clang++-10 -c sample.cpp -std=c++20
sample.cpp:16:16: error: use of overloaded operator '==' is ambiguous (with operand types 'A' and 'B')
Foo f = A{} == B{};
~~~ ^ ~~~
sample.cpp:6:18: note: candidate function [with T = B]
constexpr Foo operator==(const T&) const
^
sample.cpp:6:18: note: candidate function (with reversed parameter order) [with T = A]
1 error generated.

I can't figure out why the reversed operator is used here (tbh, I'm not a language lawyer).

Any help is appreciated, thanks!

clang++-10 --version
clang version 10.0.0-4ubuntu1~18.04.1

[dermojo]

After some digging, the issue is resolved by adding

    using X::operator==;

to the derived classes.

If this is the desired behavior, feel free to close this ticket.
Thanks.

[dermojo]

According to http://eel.is/c++draft/over.match.best (2.8 and/or 2.9), I think the non-rewritten candidate should be preferred, hence there shouldn't be any ambiguity.

The wording on cppreference is more clear though (of course it's not the standard...):

Overload resolution in this case has a final tiebreaker preferring
non-rewritten candidates to rewritten candidates, and preferring
non-synthesized rewritten candidates to synthesized rewritten candidates.

(from https://en.cppreference.com/w/cpp/language/overload_resolution)

[zygoloid]

The non-rewritten candidate is only preferred if the conversion from argument to parameter is equally good for both candidates. In this case they're not. We end up comparing

(1) X::operator==(const A&) [reversed]

against

(2) X::operator==(const B&) [non-reversed]

... and (1) has a better conversion for the A{} argument whereas (2) has a better conversion for the B{} argument, so the result is that the comparison is ambiguous: we don't know which of the above two options to use. The non-rewritten-beats-rewritten tie-breaker is never reached, because this isn't a tie.

The relevant wording is [over.match.best]p2:

"""
Given these definitions, a viable function F1 is defined to be a better function than another viable function F2 if for all arguments i, ICSi(F1) is not a worse conversion sequence than ICSi(F2), and then [...]
"""

... where we're failing the "[...] is not a worse conversion sequence [...]" for both comparisons.

[zygoloid]

It's also worth noting: the breakages caused by the operator== rewrites are well-known inside the C++ committee, and we're working on fixing them. The current front-runner candidate for a fix is to say that if you provide a matching operator== and operator!=, then the operator== is not a valid rewrite target. Would that rule have helped in this case? (Do you have a matching operator!= corresponding to your operator==?)

[rbock]

Thanks for the explanation, Richard! Is the plan to improve the situation still within C++20? Or only in C++23?

To add a bit more context:

The library mentioned by Daniel is sqlpp11, see for instance https://github.com/rbock/sqlpp11/releases/tag/0.59

Yes, it also provides the corresponding operator!=.

Daniel fixed the ambiguity he was facing by adding

public: using X::operator==;

to A. I admit that I am still having a hard time wrapping my head around the rules, but this seems fine (albeit incomplete as there are more than just the two classes and operator!= to be treated as well).

[dermojo]

Thank you both, great inside!

As a general case, the problem originates from the fact that the comparison operator(s) are part of the base class in order to allow comparison of all derived classes.

I've had the same ambiguity problem with a base "interface", containing a virtual operator==.
Defining comparison in a base class is IMHO a great way to reduce boilerplate code. I totally understand the ambiguity here, but it would be helpful if there was a simple way to circumvent this (other than defining N*N comparison functions for N sub-classes).

If an additional operator!= prevents rewriting the order of parameters, that may actually help (unless we then introduce ambiguity for a!=b vs. b!=a).

[cor3ntin]

This has been downgraded to a warning https://godbolt.org/z/cbrdPoczP