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

[Walter Bright]

On 3/12/2021 4:29 AM, deadalnix wrote:
> On Friday, 12 March 2021 at 02:06:19 UTC, Walter Bright wrote:
>> On 3/11/2021 4:57 PM, deadalnix wrote:
>>> These problems seems to arise due to the fact postblit did not distinguish 
>>> between move and copy.
>>>
>>> postblit is inappropriate for copy, but as far as I can tell, not only does 
>>> it work for move, but it's the only path that do not involve creating yet 
>>> more magic that's going to bite us in the ass at some point.
>>
>> postblit bit us in the ass quite a bit. (postblit didn't do moves)
> 
> You are making my point, yet for some reason miss it anyways.
> 
> Postblit works with *1* object. It fails at being a good copy mechanism because 
> copying involves *2* objects, by definition.
> 
> Move works with *1* object. opAssign will, similarly to what happened when using 
> postblit for copies, lead to problems because it inherently works with *2* objects.

Postblit's problems arose from it not having access to both objects. The 
opAssign does have access to both, and the qualifiers can be applied to both 
parameters, so I don't see a barrier to it working.


> Postblit is a natural fit for moves because both work with *1* object, thus not 
> leaving an object out there is some sort of magic state that we can never figure 
> out what to do with.
> 
> There is already a fair bit of magic that is proposed to be added to opAssign in 
> this proposal, yet it is now obvious to me that there are already holes in it. 
> For instance, if one of the fields of the object ends up not being moved, how 
> will this fields ends up being destroyed? How is that even fixable considering 
> the whole thing can be n-levels deep? The only way I this being fixed is be 
> reintroducing the notion that structs must have a null state and destroy the 
> object anyways post move, but going there would be a big optimization barrier, 
> while not going there creates a situation where things that should be destroyed 
> ends up not being, which is also pretty bad.
> 
> On the other hand, the postblit by its very nature does not allow for this whole 
> situation to arise to begin with. If a field is not going to be moved, it will 
> have to see some new value assigned there, causing the destruction of the old 
> value.

An opAssign gives the implementer complete control over the operation of it, 
including when and how destruction takes place of the original destination's 
contents.