Move Constructor Syntax

[Manu]

>
> Aside from whatever Walter's reasoning is, there are existing constructors
> in the wild which use
>
>     this(S)
>

I had a moment to think on this case you present.
It's not clear to me how it actually works now; but I think it would be
interesting to explore that first; because I think the solution for this
case being reinterpreted as move-constructor is related (and equally
solved).

This function receives it's arg BY-VALUE; so it can happily accept an
r-value... but it's not actually clear how this function receives an lvalue
even in today's language?
In order for this function to receive an l-value by-value, it must first
make a copy to supply as the function's argument (but the function is
allowed to internally mutate its argument)..

...but isn't *this* said to be the copy constructor?

This already looks like a chicken/egg problem in today's language... how
does it create a copy of an lvalue to pass the argument to this function
without calling this function?
Whatever answer exists that makes this work equally makes the case work
where this is reinterpreted as a move-constructor.

The only explanation I can imagine is; because this ISN'T actually a copy
constructor, the compiler determined that it was appropriate to synthesise
one (which would be to just copy all members), and so an implicit copy
constructor DOES actually exist beside this constructor, you just didn't
write it.
And assuming that's the case, when this becomes reinterpreted as a move
constructor, the code remains perfectly correct!

I don't see how elevating this declaration to a move-constructor actually
changes the semantics at all... I don't think it does? I think this
function ALREADY IS A MOVE CONSTRUCTOR (at least; it's an
rvalue-constructor, which is the same thing from a semantic perspective);
it's just working with an inefficient calling convention.
Move semantics as proposed simply improve this code, no?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20241011/4a2ab7b2/attachment-0001.htm>