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