[class.compare.secondary] The extent to which "The defaulted operator function is not considered" applies CWG2546

[xmh0511]

[class.compare.secondary] p2

The operator function with parameters x and y is defined as deleted if

• overload resolution ([over.match]), as applied to x @ y, does not result in a usable candidate, or
• the candidate selected by overload resolution is not a rewritten candidate.

Otherwise, the operator function yields x @ y. The defaulted operator function is not considered as a candidate in the overload resolution for the @ operator.

Consider this example

struct C{
    friend int operator <=>(C const&, C const&){
        return -1;
    }
    bool operator <(C const&) const = default;
};
int main(){
    C x,y;
    bool r = x<y;  // #1
}

The actual call at #1 is C::operator<(C const&) const, which is exposed by GCC and Clang. That is, they do consider the defaulted operator function as a candidate in the overload resolution for operator <. Presumably, the emphasized wording is defined for the first bullet. Is it more clear to move the wording into the point after the first bullet?

overload resolution ([over.match]), as applied to x @ y, does not result in a usable candidate; The defaulted operator function is not considered as a candidate in the overload resolution for the @ operator.

---

Another wording that is hard to read:

Otherwise, the operator function yields x @ y

What does "the operator function yields x @ y" mean? GCC and Clang expose that the definition for the defaulted operator< function uses the call to operator<=>(C const&, C const&). However, this behavior cannot be read from this wording. Presumably, the wording may mean that

The implicitly-defined default operator function performs that the expression x@y is interpreted according to the usable candidate selected as above, as defined in [over.match.oper].

Such as the above example, since operator <=> is a usable candidate, according to [over.match.oper], x<y is interpreted as (x <=> y) @ 0, the effect of the defaulted operator < will behave the same as that of (x <=> y) @ 0.

---

The improvement to [class.compare.secondary] p2

The operator function with parameters x and y is defined as deleted if

• overload resolution ([over.match]), as applied to x @ y, does not result in a usable candidate, or
• the candidate selected by overload resolution is not a rewritten candidate.

Otherwise, the implicitly-defined default operator function performs the same as that the expression x@y is interpreted according to the usable candidate, as defined in [over.match.oper].

For the purpose of this definition, the defaulted operator function is not considered as a candidate in the overload resolution for the @ operator.

[frederick-vs-ja]

Presumably, the emphasized wording is defined for the first bullet.

No, the emphasized wording is applied to both bullets. For the purpose of the definition of the defaulted comparison operator funciton, the operator function itself can't be considered as a candidate in any case.

The second bullet is used in the following (bad-written) case:

#include <compare>
struct C {
    friend auto operator<=>(C, C) = default;
    constexpr bool operator<(const C&) const { return false; }
    friend bool operator<(C, C) = default; // deleted
};
// still well-formed if < is not used or only x.operator<(y) is used

---

I think we can make the intent clearer by reordering:

For the purpose of the definition of the defaulted operator function, the operator function itself is not considered as a candidate in the overload resolution for the @ operator. The operator function with parameters x and y is defined as deleted if

• overload resolution ([over.match]), as applied to x @ y, does not result in a usable candidate, or
• the candidate selected by overload resolution is not a rewritten candidate.

Otherwise, the operator function yields x @ y. The defaulted operator function is not considered as a candidate in the overload resolution for the @ operator.

[xmh0511]

@frederick-vs-ja

For the purpose of the definition of the defaulted comparison operator funciton, the operator function itself can't be considered as a candidate in any case.

That is what I have given in the third part of this issue. "Otherwise, the operator function yields x @ y." this sentence also should be reworded.

[xmh0511]

Resulting in a usable candidate is not clear, see #5336.

[jensmaurer]

CWG2546 should address this in its suggested resolution.

[frederick-vs-ja]

Should have been fixed by #6906 (eef4c2b).