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.
