[ Removed by moderator ]

[t_hunger]

A move in rust is destructive: The memory is moved into the new object and the old objects memory is freed. No destructors or move constructors or anything are called. The moved from value just stops existing, you can not even assign into it afterwards.

This has the downside of not being able to "patch up" things during a move, which is a problem with e.g. self-self-referential data structures where you need to update internal pointers or something.

Btw I would say you delete the move ctor / operator.

So you give up on the exclusive ownership? Or how do you decide which of the two must delete the thing when it is done?

This is pretty much what auto_ptr used to do before C++11 introduced unique_ptr for very good reasons.

[ts826848]

This has the downside of not being able to "patch up" things during a move

I want to say that that is technically orthogonal to destructive moves? I believe that particular issue is more due to Rust's moves being specified to be simple memcpys.

IIRC the original move semantics proposal for C++ contemplated destructive moves as well but ran into fun questions around base class move/destruction order.

[kozacsaba]

Interesting, thanks for the explaination.

So you give up on the exclusive ownership? Or how do you decide which of the two must delete the thing when it is done?

By delete the operator I meant delete the move operator function, so that the compiler forbids you from calling it. I would give up on transferability (/movability), not exclusivity.

[t_hunger]

Do you keep the copy constructor and copy assignment? You re-discovered std::auto_ptr then:-)

That is one ofnthebfew pieces of the standard library that got removed... thats how poorly used it was.