Move Constructor Syntax

[Timon Gehr]

On 10/17/24 02:05, Manu wrote:
> On Thu, 17 Oct 2024, 07:36 Timon Gehr via Digitalmars-d, <digitalmars- 
> d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
> ...
> 
>     I agree with Manu's reasoning why having `this(ref S)` and `this(S)`
>     work as "initialization from lvalue" and "initialization from rvalue",
>     corresponding to copy and move respectively would be cleaner.
> 
>     But overall I don't have a strong preference, as dedicated syntax also
>     has some benefits. The thing I think is most important is getting the
>     semantics right.
> 
> 
> Special-casing the constructor is just admitting that the overload 
> selection mechanics are broken for **all other function calls**... It's 
> not a matter of 'preference'; if the overload mechanics work properly 
> then special casing the constructor wouldn't even be thinkable or raised 
> in conversation. It's a hack; a really dumb hack which just leaves EVERY 
> OTHER FUNCTION broken.
> 
> The fact you have "no strong preference" surprises me, maybe I've 
> misunderstood some way in which this is not a hack that's totally 
> broken?

There is a tradeoff. I think a `this(S)` has to call the destructor of 
the argument at the end of its scope. This is the right thing to do for 
normal functions, but you might expect a move constructor to not call it 
as it already destroys it as part of its normal operation. DIP1040 tried 
to fix this by _special-casing the constructor_. ;)

With a syntax based on `ref`, it is clear that there will not be a 
destructor call.

> Can you explain to me how every other function call isn't broken 
> under the special-case-for-move-constructor solution?

Move semantics still needs a separate solution, but this thread is about 
move constructors. Move constructors are not needed for move semantics, 
they are needed to manually hook moves that involve a transfer of values 
between different memory locations.

> Overload selection 
> has to work, it is basically the meat of this whole thing... there's not 
> really anything else to it.
> 
> Broken calling semantics for every function other than the constructor 
> is not a 'compromise', it baffles me that people would even consider it.
> I mean, you don't 'call' constructors so often, but you do call 
> everything else.
> 

I am completely with you here.