The liabilities of binding rvalues to ref

[Andrei Alexandrescu]

On 5/5/13 7:55 AM, Timon Gehr wrote:
> 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.

I think the same. For non-templates "auto ref" should simply accept 
rvalues and lvalues alike. Inside the function an "auto ref" parameter 
is handled as a local (i.e. disappears at the end of the function) so 
the compiler disallows returning it by reference directly with the 
current algorithms. For more complicated patterns, dynamic checking will 
pick the slack.

I'll think I'll rework my DIP for that.


Andrei