https://issues.dlang.org/show_bug.cgi?id=17448
--- Comment #14 from Andrei Alexandrescu <and...@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. --