Why const lvalue reference has priority over const rvalue reference during overloading resolution

Question

Why there is no ambiguity?

struct B {};
struct C {};

struct A
{
    A(B const &, C const &) {}
    A(B const &&, C const &&) = delete;
#if 0
    A(B const &, C const &&) = delete;
    A(B const &&, C const &) = delete;
#endif
};

B const b() { return {}; } // const result type may make sense
C const c() { return {}; } // for some user-defined types

int main()
{
    A a0{B{}, C{}}; // I want to prohibit this
    A a1{b(), c()}; // and this cases
    B const bb{};
    C const cc{};
    A a2{b(), cc}; // But surely I also want to prohibit this
    A a3{bb, c()}; // and this cases to compile
}

Here I want to store lvalue const references to B and C instances into the instance of A. Of course I want to ensure, that lifetime of referenced objects overcomes the lifetime of A's instance.

To achieve this I just = delete; overloadings for B const && and C const &&, which in addition matches B && and C && correspondingly.

Above approach works perfectly for conversion-constructors (i.e. unary ones). But it turns out, that for higher arities I have to explicitly = delete; all the combinatorically possible combinations, which encloses const rvalue reference versions of parameters of interest (i.e. #if 1).

Then I think: "Why there is no an ambiguity?", — because the ambiguity should also prevent compilation of wrong code in the above case.

So question is: "Why there is no ambiguity for mixed case of constructor's invocation?".

`B const &&` doesn't bind to an lvalue. That constructor isn't viable at all for `a3`; likewise `a2`. — T.C., Dec 23 '16 at 13:36
`B const &` can bind to anything. `B const &&` can only bind to rvalues. In the presence of both the latter is preferred over the former in the case of a rvalue(can't find the actual clause in the standard but I know it is there), thus no ambiguity. — NathanOliver, Dec 23 '16 at 13:41
related/dupe: http://stackoverflow.com/questions/17961719/overload-resolution-between-object-rvalue-reference-const-reference — NathanOliver, Dec 23 '16 at 13:46
You can if you want to. If you feel it is a dupe I can close it as a dupe and this will act as a sign post for it. — NathanOliver, Dec 23 '16 at 13:51
@NathanOliver arity greater then one and constness of rvalue reference are absent in linked question at first glance. — Tomilov Anatoliy, Dec 23 '16 at 13:53

score 6 · Accepted Answer · answered Dec 23 '16 at 15:34

6

tl;dr: It was re-designed that way.

Under the original move proposal your code would be ambiguous. Under that proposal, lvalues could bind to rvalue references, but would prefer an lvalue reference if it existed in the overload set.

Fairly late in the process, as more people began to understand the proposal, and as concepts were still being considered for C++11, the rules were changed so that lvalues could not bind to rvalue references.

I personally did not feel this change was necessary, but far more people liked the change than not liked it, and the basic functionality of move semantics would work either way. So this was definitely a compromise worth making as opposed to not getting move semantics at all.

With the change that lvalues can not bind to rvalue references, A(B const &&, C const &&) is not part of the overload resolution set if either argument is an lvalue. However A(B const &, C const &) remains in the overload set if either (or both) arguments are lvalues.

answered Dec 23 '16 at 15:34

Howard Hinnant

206,506
52
449
577

If `const &&` became able to bind all the same value categories as `const &` then, I think, problem will cease to exist. Surely, matching of corresponding categories should has a priority. – Tomilov Anatoliy Dec 23 '16 at 16:09
@Orient: You are correct. This is the original move proposal. N2812 changed that in 2009. I don't think it is feasible to reverse this change now. – Howard Hinnant Dec 23 '16 at 16:12
`const &&` is rarely used (like `auto` keyword between 90' and 10'). So if meaning of `const &&` would be changed, but meaning of `&&` preserved, then (?) nothing wrong happens? Just an imaginary case. – Tomilov Anatoliy Dec 23 '16 at 16:15
Changing the language is hard. If you want to try it, I won't shoot it down (unless I find a killer argument). But I'm not going to try it. It took a decade to get move semantics standardized, and I don't have that much fight left in me. ;-) – Howard Hinnant Dec 23 '16 at 16:17
Thank you for your great efforts. I like `&&`! – Tomilov Anatoliy Dec 23 '16 at 16:18

Why const lvalue reference has priority over const rvalue reference during overloading resolution

1 Answers1