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

2024-04-18

247. Pointer-to-member casts and function overload resolution

It is unclear whether the following code is well-formed or not:

    class A { };

    struct B : public A
    {
	void foo ();
	void foo (int);
    };

    int main ()
    {
	void (A::*f)() = (void (A::*)())&B::foo;
    }

12.3 [over.over] paragraph 1 says,

The function selected is the one whose type matches the target type required in the context. The target can be

• ...
• an explicit type conversion (7.6.1.4 [expr.type.conv], 7.6.1.9 [expr.static.cast], 7.6.3 [expr.cast]).

This would appear to make the program ill-formed, since the type in the cast is different from that of either interpretation of the address-of-member expression (its class is A, while the class of the address-of-member expression is B)

However, 12.3 [over.over] paragraph 3 says,

Nonstatic member functions match targets of type "pointer-to-member-function;" the function type of the pointer to member is used to select the member function from the set of overloaded member functions.

The class of which a function is a member is not part of the "function type" (9.3.4.6 [dcl.fct] paragraph 4). Paragraph 4 is thus either a misuse of the phrase "function type," a contradiction of paragraph 1, or an explanation of what "matching the target type" means in the context of a pointer-to-member target. By the latter interpretation, the example is well-formed and B::foo() is selected.

Bill Gibbons: I think this is an accident due to vague wording. I think the intent was

The function selected is the one which will make the effect of the cast be that of the identity conversion.

Mike Miller: The "identity conversion" reading seems to me to be overly restrictive. It would lead to the following:

    struct B {
        void f();
        void f(int);
    };
    struct D: B { };
    void (D::* p1)() = &D::f;                  // ill-formed
    void (D::* p2)() = (void (B::*)()) &D::f;  // okay

I would find the need for an explicit cast here surprising, since the downcast is a standard conversion and since the declaration of p1 certainly has enough information to disambiguate the overload set. (See also issue 203.)

Bill Gibbons: There is an interesting situation with using-declarations. If a base class member function is present in the overload set in a derived class due to a using-declaration, it is treated as if it were a derived class member function for purposes of overload resolution in a call (12.2.2 [over.match.funcs] paragraph 4):

For non-conversion functions introduced by a using-declaration into a derived class, the function is considered to be a member of the derived class for the purpose of defining the type of the implicit object parameter

There is no corresponding rule for casts. Such a rule would be practical, but if the base class member function were selected it would not have the same class as that specified in the cast. Since base-to-derived pointer to member conversions are implicit conversions, it would seem reasonable to perform this conversion implicitly in this case, so that the result of the cast has the right type. The usual ambiguity and access restrictions on the base-to-derived conversion would not apply since they do not apply to calling through the using-declaration either.

On the other hand, if there is no special case for this, we end up with the bizarre case:

    struct A {
        void foo();
    };
    struct B : A {
        using A::foo;
        void foo(int);
    }
    int main() {
        // Works because "B::foo" contains A::foo() in its overload set.
        (void (A::*)())&B::foo;
        // Does not work because "B::foo(int)" does not match the cast.
        (void (A::*)(int))&B::foo;
    }

I think the standard should be clarified by either:

• Adding a note to 12.3 [over.over] saying that using-declarations do not participate in this kind of overload resolution; or

• Modifying 12.3 [over.over] saying that using-declarations are treated as members of the derived class for matching purposes, and if selected, the resulting pointer to member is implicitly converted to the derived type with no access or ambiguity errors. (The using-declaration itself has already addressed both of these areas.)

Rationale (10/00): The cited example is well-formed. The function type, ignoring the class specification, is used to select the matching function from the overload set as specified in 12.3 [over.over] paragraph 3. If the target type is supplied by an explicit cast, as here, the conversion is then performed on the selected pointer-to-member value, with the usual restrictions on what can and cannot be done with the converted value (7.6.1.9 [expr.static.cast] paragraph 9, 7.6.1.10 [expr.reinterpret.cast] paragraph 9).