Move Constructor Syntax

[Jonathan M Davis]

On Monday, October 7, 2024 10:21:50 AM MDT max haughton via Digitalmars-d 
wrote:
> On Sunday, 6 October 2024 at 04:04:28 UTC, Walter Bright wrote:
> > ```
> > struct S { ... }
> >
> > [...]
>
> Within the language today what part of a move operation actually
> requires a new form of constructor? Isn't the whole point that
> you're just transferring ownership of a constructed object?

IIRC, the whole reason that we originally got a DIP for a move version of a
postblit (which then became a DIP for move constructors once we determined
that postblits didn't make sense due to issues with type qualifiers) is
because Weka has a use case where they store pointers to structs on the
stack in some sort of table somewhere (with other fibers accessing it on
some basis IIRC). So, if the struct ever moves, their code breaks - and as
things stand, the compiler is allowed to assume that moving a struct isn't a
problem (whereas in C++, a move constructor is required for the compiler to
move a user-defined object).

The result is that Weka has had to be _very_ careful about stuff like RVO to
ensure that these particular structs don't get moved, and they care a great
deal about which situations result in the compiler decided to move a struct
(which, fortunately for them, isn't many at this point), but if they have
move constructors, then they can hook the move and tell the table that the
address of the struct has changed, and they no longer risks bugs from stray
moves.

Personally, I've also run into one case where it made sense to pass a
pointer to a struct on the stack to another thread, and being able to
disable the ability to move that object would be quite nice even if it's not
actually required (and it wouldn't fix the situation where the struct gets
destroyed before the pointer is gone).

Now, obviously, for the vast majority of programs, move constructors are
completely unnecessary, and because we made it so that the compiler is
allowed to move objects by default, we only need move constructors in cases
where moving has to be hooked into or disallowed instead of in all cases
where it would be needed at all, but we _do_ need move constructors for any
situations where someone needs to know that a move has taken place or needs
to entirely disallow the ability to move a particular struct.

- Jonathan M Davis