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

2024-12-19

1373. Overload resolution changes matching reference-binding changes

It looks like the resolution to issue 1138 neglected to update 12.2.2.7 [over.match.ref] (in N3225) or otherwise mention it from 9.4.4 [dcl.init.ref] for the rvalue cases.

Since this is a context where overload resolution is required (to find the correct conversion function), 12.2.2.7 [over.match.ref] should probably be used (12.2 [over.match] paragraph 2); however, there are some oddities.

(Issue 1)

Consider:

    struct A {
      typedef void functype();
      operator functype&&();
    };
    void (&&x)() = A();

We are looking for a function lvalue; 12.2.2.7 [over.match.ref] (if we take it to be applicable) says the viable functions are limited to conversion functions yielding “lvalue reference” when 9.4.4 [dcl.init.ref] requires an lvalue result. The above would then fail to have any candidate conversion functions and we are left with a non-viable indirect binding to a “function temporary.”

(Issue 2)

Also, since the candidate functions in the case where an rvalue (that is prvalue or xvalue) result is required do not include ones which return lvalue references, I do not see what the wording regarding the second standard conversion sequence having an lvalue-to-rvalue transformation added in issue 1138 is meant to catch.

If the example containing

    int&& rri2 = X();

with a comment about operator int&() is a clue, then it seems that 12.2.2.7 [over.match.ref] is being ignored.

(Conclusion)

It would seem that 12.2.2.7 [over.match.ref] should apply (and be fixed to match the cases from issue1138), the verbiage about the second standard conversion is redundant, and the explanation in the example is wrong.

In particular, the previous wording for 9.4.4 [dcl.init.ref] did have distinct bullets for converting to an “lvalue” and to an “rvalue;” we now have a bullet which is not exclusively one or the other.

Possible fix

Add reference to [12.2.2.7 [over.match.ref]] in 9.4.4 [dcl.init.ref] for direct binding to rvalue reference/const non-volatile via UDC.

Remove redundent sentence referring to second SCS.

Modify example to indicate operator int&() is not a candidate function.

Clarify that the point from 9.4.4 [dcl.init.ref] below:

has a class type (i.e., T2 is a class type), where T1 is not reference-related to T2, and can be implicitly converted to an xvalue, class prvalue, or function lvalue of type “cv3 T3,” where “cv1 T1” is reference-compatible with “cv3 T3”...

is an rvalue case for 12.2.2.7 [over.match.ref] for non-function types and lvalue case for function types.

Fix 12.2.2.7 [over.match.ref] to allow candidate functions return rvalue reference to function type for lvalue cases.

Update 110510:

The example appears to be actually well-formed because the wording about the second SCS is not triggered. Falling through to indirect binding then succeeds.

Rationale (February, 2012):

This issue is a duplicate of issue 1328.