rvalue references

Zach the Mystic reachzach at gggggmail.com
Fri Apr 26 13:18:08 PDT 2013


On Friday, 26 April 2013 at 10:33:17 UTC, Timon Gehr wrote:
> On 04/26/2013 01:58 AM, Zach the Mystic wrote:
>> But as
>> you said, figuring out the rules for making the compiler smart 
>> enough to
>> choose the right one seems like a hard task.
>
> I think it is easy.
>
>> If it forwards to another
>> 'auto ref' template parameter, it needs to descend into that 
>> template,
>> determine *its* type of parameter, and then assign the type of 
>> its own
>> parameter accordingly.
>> ...
>
> No, when forwarding to another template, non-lazy parameters 
> will always have an address, ref or not ref.

This suggestion simplifies the problem greatly. Is the suggestion 
made precisely because it simplifies the problem, or do you also 
consider it better with regard to performance and safety?

> The cases where it makes a difference are auto ref returns, 
> __traits(isRef, ...), and lazy auto ref parameters. (If there 
> are more, they will be detected by grepping the compiler source 
> for occurrences of the 'ref' "storage class" representation, 
> presumably an enum value.)
>
> The compiler does not have to be particularly smart. IMO this 
> is the way to generalize auto ref to non-template functions.

I think it's useful to realize that if the end result of an 
action is the same, it's not necessary to know exactly how the 
compiler solved the problem. If both creating a temporary, and 
passing the argument to its own template-instantiated function 
produce the same semantics, then to some extent it doesn't matter 
how the compiler did it. That leaves the question of performance. 
If it were demonstrated that neither mechanism outperforms the 
other, then it *really* doesn't matter which it chooses.


More information about the Digitalmars-d mailing list