The liabilities of binding rvalues to ref

[Jonathan M Davis]

On Sunday, May 05, 2013 01:49:42 Andrei Alexandrescu wrote:
> There may be other important patterns to address at the core, please
> chime in. I consider (1) above easy to tackle, which leaves us with at
> least (2). My opinion is that any proposal for binding rvalues to ref
> must offer a compelling story about these patterns.

Another case is when you want to distinguish between lvalues and rvalues.  In 
fact, IIRC this came up in Ali's dconf talk. He had an opAssign which swapped 
guts with its argument when it was an rvalue (since it was known to be a 
temporary) and did a more normal assignment when it was an lvalue. You might 
still be able to do that if ref accepts rvalues (because the non-ref overload 
would be preferred in the rvalue case, and the ref overload would be preferred 
in the lvalue case), but I suspect that that would be incredibly error-prone - 
especially when there are multiple arguments to the function.

So, whatever solution we go with needs to allow us to reasonably overload on 
refness when we want to while still being able to have functions which accept 
both lvalues and rvalues by reference.

- Jonathan M Davis