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

[via Digitalmars-d-bugs]

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

--- Comment #14 from Andrei Alexandrescu <andrei at erdani.com> ---
(In reply to Eyal from comment #13)
> (In reply to Andrei Alexandrescu from comment #10)
> 
> > Indeed, the spec should clarify under what circumstances objects can be
> > moved.
> 
> Could we get compile-time errors when we accidentally do something that
> moves a struct that should be unmovable?
> 
> Currently we do:
> 
>   @disable this(this);
>   @disable void opAssign(typeof(this));
> 
> Could we also do:
> 
>   @disable move; // or any other syntax
> 
> So that we can remove a constant worry about accidental code that moves
> structs that shouldn't?
> 
> Getting compile-time detection of these issues is far more important than
> which exact code triggers these issues in the first place.
> 
> We can always work around detected issues. But we can't get our debugging
> time back...

That would be nice to have, but seemingly a major project both on the
definition and implementation side.

* On the language definition side: the proposal would need to differentiate
among (a) constructs that are guaranteed to not move; (b) operations that may
move if possible (for optimization purposes) or not depending on "@disable
move", and (c) operations that must always move and therefore are disallowed
for "@disable move" objects.

* On the implementation side: currently compilers embed the notion that they
can move structs around at all levels, from the front-end down to the
optimizer. Each compiler decides to move data on its own, i.e. takes full
advatage of the freedom to move. LDC for example is very adept at
"destructuring", i.e. exploding a struct into registers and "assembling" it
back if necessary. Carrying the notion of "immovable structs" through all
layers would be a major effort for all implementations.

We'd want to focus effort on things that currently make it impossible for folks
to do things (e.g. use shared portably and effectively) instead of matters that
have workarounds.

In this case, we think of having the compiler disallow escaping of &this in
safe code, i.e. constructors are scoped. For the few cases that require
escaping of the pointer, that code can be @trusted and validated by hand. On
the language definition side, we should clarify that the address of an lvalue
stays unchanged through the lifetime of the lvalue, but rvalues don't provide
such guarantees.

We're also considering a means to disable scope (e.g. by scope(false)) so
certain struct constructors and methods _are_ allowed to escape &this in a way
that is verifiable by the compiler.

On the library side, an obvious category of immovable objects are classes, so a
class in conjunction with "scope" may be a good starting point for an efficient
immovable object.

--