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