Move Constructors - Converting Lvalues to Rvalues

[Richard (Rikki) Andrew Cattermole]

On 01/10/2024 7:36 PM, Walter Bright 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.

Yes!

> Then there is the problem of 
> distinguishing between a move constructor and a copy constructor - how 
> do they overload against each other?

Why do you need to?

Are they not the same constructor, differing only for the side effects 
to the caller?

It is an assumption that the object you pass in by-ref will be the same 
object after the function call.

```d
int* someObject = ...;

int* obj = someObject;
callMe(obj);

// Does obj == someObject?
```

If you know that ``callMe`` moved the value into it, but never assigned 
to it, you can elide cleanup on ``obj``.

A question I ask myself in any sort of proving topics is what 
assumptions are being held, and can under normal usage of ``@safe`` code 
can these assumptions be invalidated, potentially desirably.

I had a look at C++, it seems the biggest difference between a copy 
constructor and a move constructor is that a move constructor is mutable 
by-ref, whereas a copy is read only. Which could indeed be overloaded 
for in D.

And yes, we could infer the difference in this regards in D too. It is 
what I have been calling "effectively-const". A rather useful thing for 
owner escape analysis, as it means methods on the owner that do not 
mutate are callable even if they cannot or have not been annotated 
``const``!