CWG2931 [over.oper] Mis-worded restriction on operator functions

[brevzin]

Reference (section label): [over.oper.general]

Issue description:

The current wording reads:

An operator function shall either

• be a member function or
• be a non-member function that has at least one non-object parameter whose type is a class, a reference to a class, an enumeration, or a reference to an enumeration.

This split doesn't make much sense, because non-member functions cannot have object parameters, so why explicitly mention non-object parameter there?

Deducing this (P0847) added:

An operator function shall either be a non-static member function or be a non-member function that has at least one non-object parameter whose type is a class, a reference to a class, an enumeration, or a reference to an enumeration.

Which, in retrospect, was probably incorrect. If that restriction applies to both "non-static member function" and "non-member function", then it disallows this for no good reason:

struct A { bool operator==(this A, int); };

If it only applies to "non-member function" (as static operator() splitting up the bullets clarified), then the restriction makes no sense.

I think the wording we want here is:

An operator function shall either

• be a member function or
• be a non-member function that has at least one non-object parameter whose type is a class, a reference to a class, an enumeration, or a reference to an enumeration.

Unless we want to disallow something like this:

struct B {
    bool operator==(this int, int);
    operator int() const;
};

in which case we probably just want to say:

An operator function shall either be a member function or be a non-member function that has at least one non-object parameter whose type is a class, a reference to a class, an enumeration, or a reference to an enumeration.

[t3nsor]

All compilers accept the operator==(this A, int) example. As for the operator==(this int, int) example, Clang and GCC accept it while EDG and MSVC reject it.

I think operator==(this int, int) should be rejected because, if we accept it, then there's no reason not to also accept non-member operator==(int, int). Both of them could be found by name lookup under appropriate circumstances where at least one operand has class type, yet we've always disallowed the second one, so for consistency the first one should be disallowed too.

[jensmaurer]

CWG2931