Rvalue references - The resolution

[Andrei Alexandrescu]

On 5/6/13 12:10 PM, Steven Schveighoffer wrote:
> The counter argument:
>
> foo(makeRvalue()); // error: cannot pass rvalues to ref
>
> // programmer: WTF? This is stupid, but ok:
>
> auto x = makeRvalue();
> foo(x);
>
> In other words, explicit nops aren't any better than implicit nops. Even
> if we *require* the user to be explicit (and it's not at all clear from
> a code-review perspective that the auto x line is to circumvent the
> requirements), the fact that this is trivially circumvented makes it a
> useless feature. It's like having const you can cast away.
>
> I think the larger issue with binding rvalues to refs is this:
>
> int foo(int i);
> int foo(ref int i);
>
> what does foo(1) bind to? It MUST bind to the non-ref, or there is no
> point for it.
>
> If this can be solved, binding rvalues to refs is fine.

I think we can technically make the overloading work while also allowing 
binding rvalues to ref. But that wouldn't help any. Consider:

ref int min(ref int a, ref int b) { return b < a ? b : a; }
...
int x;
fun(min(x, 100));

Here the result of min may be bound to an lvalue or an rvalue depending 
on a condition. In the latter case, combined with D's propensity to 
destroy temporaries too early (immediately after function calls), the 
behavior is silently undefined; the code may pass unittests.

This is a known issue in C++. Allowing loose binding of rvalues to ref 
not only inherits C++'s mistake, but also adds a fresh one.


Andrei