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

deadalnix deadalnix at gmail.com
Fri Mar 12 12:29:42 UTC 2021


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 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.


More information about the Digitalmars-d mailing list