My thoughts & tries with rvalue references

Zach the Mystic reachzach at gggggmail.com
Wed Apr 3 22:52:48 PDT 2013


On Thursday, 4 April 2013 at 01:07:08 UTC, Zach the Mystic wrote:
> 'scope ref': The only existing documentation on scope 
> parameters: http://dlang.org/function.html suggests that 
> references to them simply cannot leave the function they find 
> themselves in. But this is *not* what the temp ref feature is 
> about. Say you have this temp ref function:
>
> ref int func(@temp ref int a) { return a; }
>
> According to the spec, it clearly violates 'scope', but is 
> nonetheless valid and safe, as far as I can tell. The compiler 
> can easily track the scope of a given lvalue at the call site:
>
> static int* x;
> static int y;
> x = *func(3); // Error: result of func(3) is assumed to be local
> x = *func(y); // Pass: address of y is known to be global
>
> This kind of safety checking is not yet implemented, but is 
> suggested in DIP25, http://wiki.dlang.org/DIP25 . I believe it 
> is the right way to go. The locality of the return by reference 
> is assumed to be as local as the reference which is passed into 
> it. So the temp '3' reference would make the result of func(3) 
> yield a local, barring any other information which would allow 
> the compiler to safely assume otherwise. In essence, '@temp 
> ref' can escape its scope safely because the locality of the 
> result is not its responsibility.

On the other hand, a '@temp ref' parameter *should* be prevented 
from being assigned directly to a global, since it might be 
stack-allocated:

static int* x;
void func(@temp ref int a) {
   x = &a; // Error, 'a' might be stack-allocated
}

This *would* be an acceptable error. It's completely unsafe to 
assume that 'a' is located anywhere but the stack. But it's very 
different from a 'scope' parameter, which expressly forbids this, 
as opposed to the fortuitous coincidence that allows you to know 
that 'x = &a' is an error in this particular case. To have 'scope 
ref' implicitly mean '@temp ref' would be conflating two 
different features, I think, which only happen to have one thing 
in common.



More information about the Digitalmars-d mailing list