Skip to content

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

Description

@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.

Activity

  1. t3nsor commented on Aug 31, 2024

    @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.

  2. jensmaurer commented on Aug 31, 2024

    @jensmaurer
    Member
  3. changed the title [-][over.oper] Mis-worded restriction on operator functions[/-] [+]CWG2931 [over.oper] Mis-worded restriction on operator functions[/+] on Aug 31, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions