Move Constructor Syntax

Timon Gehr timon.gehr at gmx.ch
Sat Oct 12 21:37:22 UTC 2024


On 10/11/24 17:44, Manu wrote:
> On Thu, 10 Oct 2024, 17:22 Walter Bright via Digitalmars-d, 
> <digitalmars-d at puremagic.com <mailto:digitalmars-d at puremagic.com>> wrote:
> 
>     On 10/8/2024 11:08 PM, Jonathan M Davis wrote:
>      > So, if
>      >
>      >      this(S)
>      >
>      > suddenly becomes a move constructor, existing code will have a normal
>      > constructor suddenly turned into a move constructor.
> 
>     Yup. Kaboom.
> 
> 
> No that's wrong; this is EXACTLY the situation that move semantics exist 
> to address. Move constructor like this should ACTUALLY BE a move 
> constructor!
> 

I agree that it would be desirable to have:

```d
this(ref S){} // copy constructor
this(S){} // move constructor

void opAssign(ref S){} // copy assign
void opAssign(S){} // move assign
```

Currently this is actually what I do for `opAssign`.

However, ideally there is a way to avoid calling the destructor on the 
argument after resetting it manually. DIP1040 suggests to just not call 
it by default. I think there should be an explicit way to elide the 
destructor call. The destructor should be called by default, as this is 
the least surprising semantics.

Anyway, apparently Walter has run into some issues with the 
implementation using this syntax, so not sure this will work out. I 
don't see why it cannot work though.


More information about the Digitalmars-d mailing list