https://issues.dlang.org/show_bug.cgi?id=22916
Dennis <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|INVALID |--- --- Comment #11 from Dennis <[email protected]> --- (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. --
