CODEWITHSUNDEEP
rust
heartpunk
heartpunk

Reputation: 2275

Semantics of moves of owned pointers

This article seems to imply the possibility that the use of the term "move" in the rust documentation doesn't mean copies, but transfer of ownership at compile time. See this quote specifically:

The compiler enforces that there is only a single owner. Assigning the pointer to a new location transfers ownership (known as a move for short). Consider this program:

Is this correct? are ownership transfers/moves not actually copies at runtime, but only a compile time abstraction.

Upvotes: 2

Views: 590

Answers (1)

huon
huon

Reputation: 102056

No, a move is still a copy (in the sense of memcpy) although not necessarily of the whole data structure. However, it has the compile-time semantics that you list. That is,

let a = ~[1,2,3];
let b = a; // copies one word (the pointer), "moves" the data.

let c = b.clone(); // copies the data too.

(Note that I've used b.clone() rather than copy b, because Copy is being removed, and replaced by Clone, which is more powerful/flexible.)

This copying behaviour is required to happen, because (many) variables in Rust are definite chunks of memory (just like those in C/C++), and if something has a certain value, that value has to be in the appropriate location memory; This means moves (which usually involve transferring data from one variable to another) have to actually perform a copy.

Upvotes: 3

Related Questions