[Issue 22916] [dip1000] copy of ref return still treated as scope variable
d-bugmail at puremagic.com
d-bugmail at puremagic.com
Fri Aug 26 20:27:47 UTC 2022
https://issues.dlang.org/show_bug.cgi?id=22916
Dennis <dkorpel at live.nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---
--- Comment #6 from Dennis <dkorpel at live.nl> ---
(In reply to Walter Bright from comment #5)
> which is interpreted as `ref` and `return scope` attached to `this`. `a` is
> `this`. Since `a` is `scope`, the return value of `a.index()` is also
> `scope`.
And that's what the compiler does wrong. The `return scope` applies to the
`ref` return, not the returned `int*` value. This can be showcased by this
example:
```
ref int f(ref return scope int* x) @safe
{
return *x;
}
```
Notice how the return value has no pointers, and yet the compiler will raise an
error if you don't annotate if `return scope`. dmd will also infer this as
`return scope` itself if you make it a template.
The job of `return scope` here is to prevent returning `f(stackPointer)` by ref
or escaping `&f(stackPointer)`, but this works:
```
int g() @safe
{
int x;
int y = f(&x); // `y` is not `scope`, how could it be?
return y; // 'escaping' the result of f()
}
```
The only thing my original example does differently is giving the pointer
payload a different type (`int*` instead of `int`), which shouldn't affect
this example since it's the second layer of indirection, it shouldn't be
affected by `scope` or `return scope`.
By the way, I reduced the original example to `int**` because you usually
request that, but it might be actually illuminating to see what the original
code looked like:
```
void scoot(scope Array!string a) @safe
{
a[0] = a[1];
}
```
This obviously doesn't violate `scope` and it works with `string[]`, so it
should also work with library array types, or it's poor design of dip1000.
--
More information about the Digitalmars-d-bugs
mailing list