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

[via Digitalmars-d-bugs]

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

--- Comment #10 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to Shachar Shemesh from comment #9)
> There are two issues here. The first is that @safe does not warn about
> unsafe behavior.

Affirmative.

> Interesting, but unrelated to the Weka use case.
>
> The more interesting problem here is that certain types of programming are
> impossible in D. I was unable to find the statement in the most recent
> language specs, but the phrasing I remember from "The D Programming
> Language" was along the lines of "Structs in D may not store references to
> themselves, and therefor D may move them around memory at will".
> 
> Except that is not true. First, the order is reverse. D moves them around,
> and that's why they may not store references to themselves. More to the
> point, however, the requirement should be made much more stringent:
> 
> D structs may not manage, directly or indirectly, any reference to
> themselves, either internally as a member, or externally.
> 
> Like I stated above, that's a fairly big restriction. At the very least, the
> training material should be updated to reflect it correctly, possibly also
> the specs.
> 
> As things currently stand, there is no way to write a struct the manages its
> own registration in an outside container without using dynamic memory (which
> is never mentioned in the specs as an exception to that rule).

Indeed, the spec should clarify under what circumstances objects can be moved.
Functions manipulating objects by value can be expected to take the liberty to
move their parameters around. Functions that manipulate objects by means of
pointers and reference will not do that, even if their arguments are allocated
on the stack or statically. So certain uses of internals and mutual pointers
are possible. Currently there is no rigorous wording for such in the spec.
Contributions are welcome.

--