Title
Overload resolution for non-call of class member access
Status
drwp
Section
7.6.1.5 [expr.ref]
Submitter
Richard Smith

Created on 2023-04-26.00:00:00 last changed 3 weeks ago

Messages

Date: 2023-07-16.13:00:43

Proposed resolution (approved by CWG 2023-06-13):

Change in 7.6.1.5 [expr.ref] bullet 6.3 as follows:

  • ...
  • If E2 is an overload set, the expression shall be the (possibly-parenthesized) left-hand operand of a member function call (7.6.1.3 [expr.call]), and function overload resolution (12.2 [over.match]) is used to select the function to which E2 refers. The type of E1.E2 is the type of E2 and E1.E2 refers to the function referred to by E2.
    • If E2 refers to a static member function, E1.E2 is an lvalue.
    • Otherwise (when E2 refers to a non-static member function), E1.E2 is a prvalue. The expression can be used only as the left-hand operand of a member function call (11.4.2 [class.mfct]). [Note 5: Any redundant set of parentheses surrounding the expression is ignored (7.5.3 [expr.prim.paren]). —end note]
  • ...

This also addresses issue 1038.

Date: 2023-11-15.00:00:00

[Accepted as a DR at the November, 2023 meeting.]

Consider:

  struct A {
    static void f();
    static void f(int);
  } x;
  void (*p)() = x.f;   // error

This is ill-formed as confirmed by issue 61. Various other changes (see issue 2241) have put the following example into the same category:

  struct B {
    static void f();
  } y;
  void (*q)() = y.f;   // error

If this is the intended outcome (although major implementations disagree), then the rules in 7.6.1.5 [expr.ref] should be clarified accordingly.

History
Date User Action Args
2024-04-05 21:43:46adminsetstatus: dr -> drwp
2023-12-19 10:15:28adminsetstatus: ready -> dr
2023-11-10 06:40:38adminsetstatus: tentatively ready -> ready
2023-07-16 13:00:43adminsetstatus: open -> tentatively ready
2023-05-01 15:44:10adminsetmessages: + msg7269
2023-04-26 00:00:00admincreate