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