On Tue, 1 Oct 2024, 17:03 Walter Bright via Digitalmars-d, <digitalmars-d@puremagic.com> wrote:
On 9/30/2024 8:29 PM, Richard (Rikki) Andrew Cattermole wrote:
> Perhaps an attribute, like ``@move`` in core.attributes would be sufficient for
> this task ;)


It's an interesting idea, but a lot of details would need to be worked out. For
instance, the core.attributes.move is a version of the move assignment operator,
not move construction. Then there is the problem of distinguishing between a
move constructor and a copy constructor - how do they overload against each
other? There's what a default move constructor should be. There's what happens
when a field of a struct has a move constructor.

And so on.

BTW, I took a look at core.lifetime.move. It's hard to figure out just what it
does, as there are vacuous forwardings to other templates.

For example:
```
void move(T)(ref T source, ref T target)
{
     moveImpl(target, source);
}
```
Why?

Because D is so fundamentally broken in this department. Work your way through a clear understanding of core.lifetime, and you should become convinced how important this work you are doing actually it's!