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

[deadalnix]

On Thursday, 18 March 2021 at 09:51:27 UTC, Walter Bright wrote:
> If a field with a move constructor is added to a struct S 
> without one, a default move constructor will be created for S 
> that calls the field's move constructor.
>

This is all good so far.

> If one is added to a struct with an explicit move constructor, 
> it is up to the struct programmer to fold it in explicitly, 
> just like he does for explicit constructors and destructors.

As explained in 
https://forum.dlang.org/post/bkfqchwpnonngjrtybbe@forum.dlang.org 
, this is where things go wrong. There are a few ways this can be 
designed, but they all drop some important property that would be 
detrimental overall as we don't gain much in return.

The error that you are making is that it is fundamentally 
different from ctor and dtor in nature. Yes, in both cases, you 
expect the dev to do something sensible, but the comparison stop 
there. And you know it is not enough, because if that was, then 
why do array bound checks? or have ctor/dtor at all to begin 
with? Just call the destroy function in all codepath and be done 
with it!

The reality is that the set of assumption broken here is much 
larger than for ctor/dtor, even going as far as breaking 
assumptions provided by ctor/dtor, such as guaranteed pairwise 
construction/destruction.