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

[Imperatorn]

On Friday, 12 March 2021 at 06:52:09 UTC, tsbockman wrote:
> On Friday, 12 March 2021 at 01:43:01 UTC, tsbockman wrote:
>> On Friday, 12 March 2021 at 01:40:22 UTC, tsbockman wrote:
>>> [...]
>
> Nope, still not correct. I had a bug in the surrounding 
> context, and wasn't testing enough things. Here's another 
> attempt that passes a more thorough test:
>     
> https://gist.github.com/run-dlang/b789714c01905f091a44ee2666276433
>
> The important bit:
>
> /* move construction and assignment (these must be called 
> manually
> and do not use the DIP syntax, since it's not implemented yet): 
> */
> void moveConstruct(ref S source) @system nothrow @nogc {
>     // @system since this must not be called by itself on an 
> already-initialized object.
>     if(source.isUnique) {
>         ptr = &internal;
>         internal = source.internal;
>     } else
>         ptr = source.ptr;
>     source.ptr = null;
> }
> void moveAssign(ref S source) @trusted nothrow @nogc {
>     static if(useDIPLowering) {
>         // destroy after (the DIP's proposal):
>         S newVal = void;
>         newVal.moveConstruct(source);
>         S oldVal = void;
>         oldVal.moveConstruct(this);
>         moveConstruct(newVal);
>         // Implicitly destruct(oldVal).
>     } else {
>         // conditionally move and destroy before (my proposal):
>         if(&source !is &this) {
>             destruct(this);
>             moveConstruct(source);
>         }
>     }
> }
>
> Key changes: the move constructor must put the source into a 
> state where the destructor is a no-op, and for the move 
> assignment operation to destroy the old value *after* the move, 
> as required by the DIP, TWO extra moves are required. That is a 
> lot of extra work and confusion just to avoid explicitly 
> checking if the source and destination are the same. This seems 
> especially silly given that the optimizer can probably detect 
> the move-to-self case at compile time in many cases, and 
> eliminate either the test, or the entire move during 
> compilation.
>
> Is there some other motivation for destroying after, rather 
> than before, besides the self-move case?

Not trying to be rude, but it's a bit worrying that even those 
who know D really well have a hard time understanding the DIP... 
(I don't count myself as one of them yet)

Maybe it should provide even more "end-to-end" code examples to 
show how all parts work?

Maybe we're over-analyzing things, idk, but I guess we want to be 
sure everything is 100% correct and can be explained (relatively 
easy) to a certain percentage of the community.

The discussion implies there are parts not fully understood and 
that makes people nervous.