<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 13 Oct 2024, 07:17 Timon Gehr via Digitalmars-d, <<a href="mailto:digitalmars-d@puremagic.com">digitalmars-d@puremagic.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/11/24 09:25, Manu wrote:<br>
> I don't see how elevating this declaration to a move-constructor <br>
> actually changes the semantics at all... I don't think it does? I think <br>
> this function ALREADY IS A MOVE CONSTRUCTOR (at least; it's an rvalue- <br>
> constructor, which is the same thing from a semantic perspective); it's <br>
> just working with an inefficient calling convention.<br>
> Move semantics as proposed simply improve this code, no?<br>
<br>
DIP1040 suggests to pass the argument implicitly by reference and to not <br>
call the destructor on it.<br>
<br>
As I mentioned in my DConf talk, this can lead to accidental memory <br>
leaks. Particularly if it is existing code that previously assumed the <br>
destructor will run.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I feel like we resolved this; we agreed that the no destructor call in 1040 was a mistake. If the callee decides to do anything invasive with its argument, like stealing it's allocations in a move operation, it must return it to a destructible state. The memory's lifetime in the calling code would continue, and call the destructor as usual.</div><div dir="auto"><br></div><div dir="auto">I felt confident we agreed on that requirement and it resolved the issues you illustrated? </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another point where it will differ is automatic generation of move <br>
constructors and move `opAssign`. I think now it has to be done manually <br>
or you get copies.<br>
<br>
Finally, for some reason, at the moment you cannot have both `this(ref <br>
S)` and `this(S)`. But `opAssign(ref S)` and `opAssign(S)` works. This <br>
moves around values in memory a bit more often though. A semantic move <br>
may just pass a reference further down the call stack.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, pretty much the entire point of this work is enabled passing the point "further down the line", copying at each function boundary is precisely the problem to be solved.<br></div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">(IIRC non-POD <br>
struct types are always passed by `ref` in the ABI.)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Yes, essentially, we're just acknowledging in the language semantics what is already true in the ABI.</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>