This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115c. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.

2024-09-25

2687. Calling an explicit object member function via an address-of-overload-set

Section: 12.2.2.2.1  [over.match.call.general]     Status: C++23     Submitter: Matthew House     Date: 2023-01-16

[ Resolved by paper P2797R0, adopted in February 2023. ]

Subclause 12.2.2.2.1 [over.match.call.general] paragraph 2 specifies:

If the postfix-expression is the address of an overload set, overload resolution is applied using that set as described above. If the function selected by overload resolution is a non-static member function, the program is ill-formed.

However, 7.6.2.2 [expr.unary.op] paragraph 3 states that the address of an explicit object member function is a plain pointer to function, not a pointer to member. The former can be invoked using the regular function call syntax (7.6.1.3 [expr.call]) without the need for a pointer-to-member expression (7.6.4 [expr.mptr.oper]). For example, absent any overloading and given some function f, the expression (&A::f)(A()) could be valid if f is a static member function or an explicit object member function. However, that expression cannot possibly be valid if f is an implicit object member function.

Proposed resolution (approved by CWG 2023-01-27):

Change in 12.2.2.2.1 [over.match.call.general] paragraph 2 as follows:

If the postfix-expression is the address of an overload set, overload resolution is applied using that set as described above. If the function selected by overload resolution is a non-static an implicit object member function, the program is ill-formed.

EWG 2023-02-06

Subclause 12.3 [over.over] paragraph 4 says that explicit-object member functions match both kinds of pointer type, and 11.4.3 [class.mfct.non.static] paragraph 2 seems to try to transform (&A::f)(A()) into (&(*this).A::f)(A()) if f is an explicit-object member function.

Editor's observation: 12.3 [over.over] paragraph 4 was a missed edit applying P0847R7; it was rectified with commit 0c9dd96bb on 2023-01-17.

Additional notes (March, 2023)

The concern about incorrectly applying the this transformation was addressed by P2797R0 (Proposed resolution for CWG2692 Static and explicit object member functions with the same parameter-type-lists).