Move Constructor Syntax

[RazvanN]

On Friday, 11 October 2024 at 07:25:53 UTC, Manu wrote:
>>
>> 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!
>
The only problem is that in today's language you cannot have a
copy constructor and a move constructor defined. It's an error!
When I implemented the copy constructor I discovered this problem:
if the copy constructor is in the same overload set as the rest of
the constructors then the overload resolution would enter in an 
infinite
loop, so my proposition was to keep the syntax, but simply place 
the
copy constructor in a different overload set (__copyctor as 
opposed to __ctor).
However, Walter was against it and preferred that we disallow the 
definition
of both copy ctor and rvalue ctor for an object.

However, I think this can be fixed if we keep the same syntax 
(`this(typeof(this))`) for a move constructor, but simply place 
it in a different
overload set (__movector). That way, if we have __copyctor, 
__movector and __ctor the compiler can reason on which one should 
be called depending on the circumstances and thus infinite loops 
can be avoided.

> 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?