[Issue 22916] [dip1000] copy of ref return still treated as scope variable

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Aug 29 09:39:35 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 #11 from Dennis <dkorpel at live.nl> ---
(In reply to Walter Bright from comment #9)
> That difference makes all the difference.

No it does not. Whether I have a `scope int[]` or `scope string[]`, the scope
only applies to the first indirection of the array, not the array elements. If
I index a `scope string[]` and get a `scope string`, it's a bug.

> The trouble is the code is trying to store a scope protected value `int* p`
> into the unprotected payload pointer `*ptr`. There's no way dip1000 can do that.

Of course not, but the issue is that it shouldn't be a scope protected value in
the first place because it came from a dereferenced pointer, after which
`scope` shouldn't apply anymore. This is deduced from the function signature
using `return scope` by the way, NOT from the return expression.

Please stop closing this issue based on false premises. 

I'm not incorrectly annotating the function `return scope`.
I'm not trying to cheat transitive scope.
I'm not asking to inspect the return expression to gain more information than
the function signature provides.
I'm not saying a scope pointer may be assigned to a non-scope parameter.

> You'll have to use @trusted code.

The whole point of dip1000 is that stack-allocated arrays become usable in
@safe code. If we can't allow indexing or assigning array elements without
@trusted, it defeats the purpose.

--


More information about the Digitalmars-d-bugs mailing list