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