Move Constructor Syntax

[Timon Gehr]

On 10/12/24 10:06, Manu wrote:
> 
>     4. rvalue constructors exist and are used, and are NOT move constructors
> 
> 
> They are rvalue constructors; it doesn't matter what they do, their 
> selection criteria remains identical.

Just as long as the semantics of the actual declaration does not change. 
DIP1040 proposed to change the semantics of the move constructor 
declaration itself.

Anyway, I agree that a clean design may be that a constructor that 
accepts an lvalue of the same type should be a copy constructor and a 
constructor that accepts an rvalue of the same type should be a move 
constructor (templated or not). Without any special semantics of the 
declaration itself.

Then standard overload resolution (with an after-the-fact check whether 
there is `ref` on the first parameter) can be used to check whether 
something is copyable or moveable.


I guess one change in behavior is that code that previously worked with 
implicit compiler-generated moves or explicit moves will now invoke 
something that had been written as an rvalue constructor, which also 
precluded there being any user-defined copy constructor in the struct or 
its fields (disabled or otherwise).

I am not sure for what purpose rvalue constructors are even being 
written today, but I think the only way to invoke them is as an explicit 
`S(s)`. If someone does something funky in such a constructor, it may 
not actually do the right thing if it suddenly starts being called for 
moves.