The liabilities of binding rvalues to ref

[Timon Gehr]

On 05/05/2013 07:49 AM, 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.
> ...

Any solution that allows both lvalues and rvalues to bind to the same 
reference will have problem (2), and fixing up problem (1) introduces 
somewhat arbitrary rules. Probably we do not want to have to deal with 
them by default.

A possibility would be to fix (2) in a similar way to the proposed 
solution for (1): Only allow rvalues to bind to 'ref' if they cannot be 
turned into lvalues by changing the signature of a different function. I 
don't like this solution very much.

I still think auto ref should be extended to work for non-templated 
functions. The semantics should be the same (i.e. behave as if there 
were two copies that are eagerly semantically analyzed, but only 
generate code for one) where possible. It would be an error to have 
different behaviour of the two "copies". This would mean that in 
non-templated functions, it should be an error to rely on whether or not 
the passed argument was an lvalue. i.e. (auto) ref return of an auto ref 
argument (at least in @safe code) and __traits(isRef,autoRefArgument) 
should be disallowed. This would have the effect of making it illegal to 
return references to temporaries from functions (at least in @safe 
code), and hence the life time of rvalues would not have to be changed.

Both (1) and (2) would be close to non-issues with this solution.