Overloading operator== with `&&` and `const` qualifier cause ambiguity in C++20

Consider the struct S with two operator== overloads of same && qualifier and different const qualifier:

struct S {
  bool operator==(const S&) && { 
    return true;
  }
  bool operator==(const S&) const && { 
    return true;
  }
};

If I compare the two S with operator==:

S{} == S{};

gcc and msvc accept this code, clang rejects it with:

<source>:14:7: error: use of overloaded operator '==' is ambiguous (with operand types 'S' and 'S')
  S{} == S{};
  ~~~ ^  ~~~

Why does clang think there is an ambiguous overload resolution here? Shouldn't the non-const one be the best candidate in this case?

Similarly, if I compare two S with the synthesized operator!=:

S{} != S{};

gcc still accept this code, but msvc and clang doesn't:

<source>:14:7: error: use of overloaded operator '!=' is ambiguous (with operand types 'S' and 'S')
  S{} != S{};
  ~~~ ^  ~~~

It seems weird that the synthesized operator!= suddenly causes the ambiguity for msvc. Which compiler is right?

The example would be unambiguous in C++17. C++20 brings change:

[over.match.oper]

For a unary operator @ with an operand of type cv1 T1, and for a binary operator @ with a left operand of type cv1 T1 and a right operand of type cv2 T2, four sets of candidate functions, designated member candidates, non-member candidates, built-in candidates, and rewritten candidates, are constructed as follows:

...

For the operator ,, the unary operator &, or the operator ->, the built-in candidates set is empty. For all other operators, the built-in candidates include all of the candidate operator functions defined in [over.built] that, compared to the given operator,

have the same operator name, and

accept the same number of operands, and

accept operand types to which the given operand or operands can be converted according to [over.best.ics], and

do not have the same parameter-type-list as any non-member candidate that is not a function template specialization.

The rewritten candidate set is determined as follows:

...

For the equality operators, the rewritten candidates also include a synthesized candidate, with the order of the two parameters reversed, for each non-rewritten candidate for the expression y == x.

Thus, the rewritten candidate set includes these:

 implicit object parameter
 |||
(S&&, const S&);       // 1
(const S&&, const S&); // 2

// candidates that match with reversed arguments
(const S&, S&&);       // 1 reversed
(const S&, const S&&); // 2 reversed

The overload 1 is better match than 2, but the synthesised reversed overload of 1 is ambiguous with the original non-reversed overload because both have const conversion to one parameter. Note that this is actually ambiguous even if overload 2 doesn't exist.

Thus, Clang is correct.

This is also covered by the informative compatibility annex:

Affected subclause: [over.match.oper] Change: Equality and inequality expressions can now find reversed and rewritten candidates.

Rationale: Improve consistency of equality with three-way comparison and make it easier to write the full complement of equality operations.

Effect on original feature: Equality and inequality expressions between two objects of different types, where one is convertible to the other, could invoke a different operator. Equality and inequality expressions between two objects of the same type could become ambiguous.
struct A {
  operator int() const;
};

bool operator==(A, int);        // #1
// #2 is built-in candidate: bool operator==(int, int);
// #3 is built-in candidate: bool operator!=(int, int);

int check(A x, A y) {
  return (x == y) +             // ill-formed; previously well-formed
    (10 == x) +                 // calls #1, previously selected #2
    (10 != x);                  // calls #1, previously selected #3
}

Recommended topics

Hot tags