Rvalue references - The resolution

[Steven Schveighoffer]

On Sat, 04 May 2013 19:30:21 -0700, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> However, if we had an attribute which explicitly designated that a  
> function
> accepted both rvalues and lvalues (which is what auto ref was originally
> supposed to do as Andrei proposed it), then if you saw
>
> auto foo(ref int i);
> auto bar(auto ref int i);
>
> then you could be reasonably certain that foo was intending to alter its
> arguments and bar was not.

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.

-Steve