On Sunday, August 26, 2018 5:10:29 PM MDT Nicholas Wilson via Digitalmars-d- learn wrote: > On Sunday, 26 August 2018 at 20:17:30 UTC, aliak wrote: > > So if we had this: > > > > struct A(T) { > > > > auto proxy() @trusted { > > > > return B!T(&this); > > > > } > > > > } > > > > struct B(T) { > > > > private A!T* source; > > private this(A!T* s) { source = s; } > > @disable this(); > > @disable this(this) {} > > @disable void opAssign(B!T); > > > > } > > > > In order for f to be "safe" I need to ensure that B!T(&this) > > does not escape the scope of A!T. I figured disable > > construction and copying may work, but it seems you can still > > get it moved: > > > > void main() @safe { > > > > auto f() { > > > > auto a = A!int(); > > return a.proxy; > > > > } > > auto escaped = f; // escaped.source is gone... > > > > } > > > > Anyway around this? > > > > Cheers, > > - Ali > > Not sure abut the current language but DIP1014 > https://github.com/dlang/DIPs/blob/master/DIPs/DIP1014.md#final-review > > "The point was made that allowing opPostMove to be overidden > raises the question of what to do when it is annotated with > @disable. The concensus was that, in such a case, an actual > attempt to move the object would result in a compilation error." > > So, soon™?
Yeah. Hopefully, we're able to disable moving at some point in the near future. However, right now, it's definitely not possible. So, if you have a type where it won't work properly if it's ever moved, then either you need to rethink what you're doing, or you must be _very_ careful with how you use any object of that type so that you don't ever use it in a way that even might result in it being moved. - Jonathan M Davis