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

[Walter Bright]

On 3/18/2021 11:12 AM, Timon Gehr wrote:
> In condensed form, I think the main complaint is this. Let's start with a struct:
> 
> struct S{
>      T field0;
>      this(S r){
>          field0=move(r.field0);
>      }
> }
> 
> 
> Now someone adds a new field, but forgets to update the move constructor:
> 
> struct S{
>      T field0, field1;
>      this(S r){
>          field0=move(r.field0);
>      }
> }
> 
> field1 is now leaked: _Its destructor will never run_. And this can happen in 
> @safe code. (Ignoring the issue that field1 of the moved object will be the init 
> value.)

Thanks, I understand it now.

> This design is error-prone. postblit does not have this issue, because fields 
> that are not explicitly referred to are moved correctly by default.
> 
> Hence the suggestion in my previous post to perhaps require all fields to be 
> initialized in a move constructor and similar thoughts about opAssign.
> This mitigates the risk, but unfortunately it does not eliminate it. (It is 
> furthermore possible that such an error would be annoying in some cases.)

Not sure how it doesn't eliminate the risk. The compiler already does some flow 
analysis in constructors (to implement restrictions about when constructor calls 
can occur).