https://issues.dlang.org/show_bug.cgi?id=17448
Jonathan M Davis <issues.dl...@jmdavisprog.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |issues.dl...@jmdavisprog.co | |m --- Comment #29 from Jonathan M Davis <issues.dl...@jmdavisprog.com> --- (In reply to Tomer Filiba (weka) from comment #27) > I don't suppose this would help. It seems the & operator is just not allowed > in safe code: > > void main() @safe { > int x; > auto tmp = &x; // Error: cannot take address of local x in @safe > function > } That code becomes @safe with -dip1000, because then it's inferred as scope, and the compiler verifies that it doesn't escape, whereas without DIP 1000 and its improvements to scope, the compiler doesn't have any way to ensure that the resulting pointer is used in an @safe manner. So, DIP 1000 should have a fairly large impact on how @safe certain operations are. (In reply to Tomer Filiba (weka) from comment #28) > My point is, @safe is so constrained that it's practically unusable, so I > don't consider it a viable solution for this problem. That would be highly dependent on what your code is doing and how willing you are to vet code and mark functions @trusted where appropriate or use @trusted lambdas to mark sections of code as @trusted (which isn't the most ideal solution for marking a section of code as @trusted, but it's the best we have right now). If you're constantly doing stuff like taking the address of a local variable, then yes, @safe is going to be a miserable mess (though DIP 1000 may fix that). But a lot of code can be @safe with no problem. It really depends on the type of stuff your code is doing. --