| |
| Posted by Richard (Rikki) Andrew Cattermole in reply to Walter Bright | PermalinkReply |
|
Richard (Rikki) Andrew Cattermole
Posted in reply to Walter Bright
| 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``!
|