Overload resolution of &x.static_func
tentatively ready
12.3 [over.over]
Mike Miller

Created on 2010-03-02.00:00:00 last changed 2 months ago


Date: 2023-07-16.13:00:43

CWG 2023-06-12

The clarifications in P1787R6 did not address the core of this issue, so it is kept open. In order to avoid confusion, a wording change to clarify the treatment (regardless of direction) seems advisable. CWG felt that the first and second examples should be treated consistently, and expressed a mild preferences towards making those ill-formed. It was noted that the reference to id-expression in 12.3 [over.over] can be understood to refer to the id-expression of a class member access.

This issue is resolved by issue 2725.

Date: 2023-02-15.00:00:00

Additional notes (February, 2023)

This appears to be resolved, in part by P1787R6 (accepted November, 2020).

Date: 2010-10-15.00:00:00

Additional note (October, 2010):

A related question concerns an example like

    struct S {
        static void g(int*) {}
        static void g(long) {}
    } s;

    void foo() {

Because the address occurs in a call context and not in one of the contexts mentioned in 12.3 [over.over] paragraph 1, the call expression in foo is presumably ill-formed. Contrast this with the similar example

    void g1(int*) {}
    void g1(long) {}

    void foo1() {

This call presumably is well-formed because [over.match.call] applies to “the address of a set of overloaded functions.” (This was clearer in the wording prior to the resolution of issue 704: “...in this context using &F behaves the same as using the name F by itself.”) It's not clear that there's any reason to treat these two cases differently.

This question also bears on the original question of this issue, since the original wording of [over.match.call] also described the case of an ordinary member function call like s.g(0L) as involving the “name” of the function, even though the postfix-expression is a member access expression and not a “name.” Perhaps the reference to “name” in 12.3 [over.over] should be similarly understood as applying to member access expressions?

Date: 2022-02-18.07:47:23

The Standard is not clear whether the following example is well-formed or not:

    struct S {
        static void f(int);
        static void f(double);
    S s;
    void (*pf)(int) = &s.f;

According to [expr.ref] bullet 4.3, you do function overload resolution to determine whether x.f is a static or non-static member function. [expr.unary.op] paragraph 6 says that you can only take the address of an overloaded function in a context that determines the overload to be chosen, and the initialization of a function pointer is such a context (12.3 [over.over] paragraph 1) . The problem is that 12.3 [over.over] is phrased in terms of “an overloaded function name,” and this is a member access expression, not a name.

There is variability among implementations as to whether this example is accepted; some accept it as written, some only if the & is omitted, and some reject it in both forms.

Date User Action Args
2023-07-16 13:00:43adminsetstatus: open -> tentatively ready
2023-06-12 16:01:03adminsetmessages: + msg7311
2023-06-12 16:01:03adminsetstatus: review -> open
2023-02-12 18:14:40adminsetmessages: + msg7200
2023-02-12 18:14:40adminsetstatus: open -> review
2010-10-18 00:00:00adminsetmessages: + msg3038
2010-03-02 00:00:00admincreate