digitalmars.D.learn - Can passing an address of this to a non-copyable object be made
- aliak (26/26) Aug 26 2018 So if we had this:
- Nicholas Wilson (8/35) Aug 26 2018 Not sure abut the current language but DIP1014
- Jonathan M Davis (9/60) Aug 26 2018 Yeah. Hopefully, we're able to disable moving at some point in the near
- aliak (4/14) Aug 27 2018 I guess I'll just stay @system for now then. Maybe I'll be able
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
Aug 26 2018
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, - AliNot 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™?
Aug 26 2018
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: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 DavisSo 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, - AliNot 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™?
Aug 26 2018
On Monday, 27 August 2018 at 00:15:18 UTC, Jonathan M Davis wrote:On Sunday, August 26, 2018 5:10:29 PM MDT Nicholas Wilson viaBah humbug. Was afraid of this :pSo, 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 DavisI guess I'll just stay system for now then. Maybe I'll be able to figure something out some time.
Aug 27 2018