Bug 18281 – Compiler rejects safe code in @safe

Status
RESOLVED
Resolution
INVALID
Severity
normal
Priority
P1
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2018-01-23T01:33:23Z
Last change time
2018-01-25T12:03:57Z
Keywords
rejects-valid, safe
Assigned to
No Owner
Creator
Mike Franklin

Comments

Comment #0 by slavo5150 — 2018-01-23T01:33:23Z
void main() @safe { string foo = "foo"; string*[] ls; ls ~= &foo; } onlineapp.d(6): Error: cannot take address of local foo in @safe function main https://run.dlang.io/is/ecYAKZ There is no escaping reference, so I don't see why the compiler is rejecting this code.
Comment #1 by dfj1esp02 — 2018-01-23T08:05:01Z
I believe accepting all Turing-complete safe code would require solution to halting problem, so type system is necessarily conservative: what passes is safe, but so much about it. DIP1000 extends scope of accepted safe code.
Comment #2 by nick — 2018-01-24T11:07:09Z
anonymous4: The following code works with -dip1000, so this is nothing to do with Turing completeness, but this bug is still invalid: void main() @safe { string foo = "foo"; string* p = &foo; string*[] arr = [&foo]; } `p` and `arr` are inferred as scope. In the original code, there are no initializers so dmd can't infer scope. The compiler should mention that the assignment fails because the assignee is not scope though.
Comment #3 by dfj1esp02 — 2018-01-25T12:03:57Z
(In reply to Nick Treleaven from comment #2) > dmd can't infer scope That's what I mean: the code is safe, but the compiler is not smart enough to figure it out. There's no such requirement that there must be safe code that must not ever be recognized as safe, and dip1000 is the primary example of that: language rules can be extended to accept more safe code, effectively it's prone to "can't say no" problem.