Discussion Thread: DIP 1040--Copying, Moving, and Forwarding--Community Review Round 1

tsbockman thomas.bockman at gmail.com
Fri Mar 12 01:43:01 UTC 2021


On Friday, 12 March 2021 at 01:40:22 UTC, tsbockman wrote:
> On Thursday, 11 March 2021 at 21:45:49 UTC, tsbockman wrote:
>> You can put the lowering logic inside of the move opAssign 
>> instead, but it doesn't change the fundamental problem. If no 
>> actual general-purpose lowering is possible that accurately 
>> reflects the intended semantics of, "After the move is 
>> complete, the destructor is called on the original contents of 
>> the constructed object," then the DIP's description of the 
>> semantics is simply incorrect and should be replaced with 
>> something more rigorous.
>
> I think I finally figure out how to make some sense out of the 
> DIP's description. However, the lowering cannot be expressed 
> clearly with the DIP's syntax, so I will use an alternative 
> notation:
>
> void moveConstruct(ref S source) nothrow @nogc {
>     if(source.isUnique) {
>         ptr = &internal;
>         internal = source.internal;
>     } else
>         ptr = source.ptr;
> }
> void moveAssign(ref S source) @trusted nothrow @nogc {
>     S oldDest = void;
>     oldDest.moveConstruct(this); // Move the old value to a 
> temporary.
>     moveConstruct(source);
>     // Implicitly destroy the old value.
> }
>
> Is this correct? If so, the DIP really needs to explain it more 
> clearly - especially if the user is expected to implement some 
> equivalent in the custom move operator himself, rather than the 
> compiler doing it for him.

Updated runnable example, for context:
     
https://gist.github.com/run-dlang/c5805ebb9e9b9734e032ca5e81fcfa90

This version seems to work correctly with either lowering enabled.


More information about the Digitalmars-d mailing list