On 01/10/2024 4:11 PM, Walter Bright wrote:
> On 9/30/2024 1:28 PM, Richard (Rikki) Andrew Cattermole wrote:
>> 1. Nobody has been able to answer what the purpose of them is
> 
> Performance.

Ah huh!

Now I'm on board with us having move constructors.

On 9/30/2024 10:49 AM, Dukc wrote:
> Doesn't `core.lifetime.move` already do this?

Since the compiler doesn't know about it, the potential for optimizations, lifetime analysis, etc., is lost.

On 01/10/2024 4:22 PM, Walter Bright wrote:
> On 9/30/2024 10:49 AM, Dukc wrote:
>> Doesn't `core.lifetime.move` already do this?
> 
> Since the compiler doesn't know about it, the potential for optimizations, lifetime analysis, etc., is lost.

If only there was a way that was backwards compatible, for us to annotate on a parameter that it invalidates the input in the form of a move.

Perhaps an attribute, like ``@move`` in core.attributes would be sufficient for this task ;)

On 9/30/2024 10:27 AM, Bastiaan Veelo wrote:
> I suppose `-preview=rvaluerefparam` is not relevant here, right?

It should be irrelevant here.

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?

On 9/30/2024 9:55 PM, Per Nordlöw wrote:
> Ideally I would like to have a special syntax for converting an l-value to an r-value.

Manu suggested an intrinsic, something like:

```
__rvalue(s)
```
where __rvalue is a keyword.

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``!