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

[tsbockman]

On Tuesday, 16 March 2021 at 08:22:07 UTC, Walter Bright wrote:
> On 3/15/2021 1:09 PM, tsbockman wrote:
>> I was trying to figure out what your original, general-purpose 
>> move *assignment* algorithm could be. That's what my code 
>> example is for.
>
> The answer is, it depends on how the programmer set up the 
> contents of the object, in particular, how the ownership works.
> It's up to the programmer to make it work so the user of the 
> type sees the semantics as described.

The semantics as described in the DIP are unsound. You've left 
out some implied extra step or assumption.

> For example, if it's pointing to unique objects, then the 
> destructor for the destination is called first. If it's 
> pointing to ref counted objects, then the destructor is called 
> last.

When the source and destination refer to the same object, that 
object still ends up either destroyed, or in an invalid state, 
regardless of which order a single move and destruction are 
performed.

You stated earlier that making such self-moves work correctly is 
the specific motivation for the current wording in the DIP, but 
it clearly doesn't do that in either of your examples.

I've tested this with actual runnable code, so please stop 
responding like I just don't get it, unless you're going to 
critique the code example itself.

> The language doesn't specify that. The programmer does, and the 
> programmer needs to make it work. Hence the "as if" rule.

An algorithm that works "as if" it prematurely destroys the 
object in self-moves, must still prematurely destroy the object 
in self moves. The "as if" rule allows different implementations, 
not different results.

You just have different results in mind from what your wrote in 
the DIP.