The liabilities of binding rvalues to ref

[Timon Gehr]

On 05/05/2013 01:55 PM, Timon Gehr wrote:
> 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.

It seems to make sense that template function instantiations should be 
split into two copies per auto ref argument only if it is necessary to 
support differing semantics for lvalues and rvalues.

Peter Alexander brings up a good point regarding the implicit this 
reference for structs. Probably it should be passed by auto ref.