[Issue 17448] Move semantics cause memory corruption and cryptic bugs

[d-bugmail at puremagic.com]

https://issues.dlang.org/show_bug.cgi?id=17448

Jonathan M Davis <issues.dlang at jmdavisProg.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |issues.dlang at jmdavisProg.co
                   |                            |m

--- Comment #29 from Jonathan M Davis <issues.dlang at 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.

--