Variables and Data Interacting with Move
Multiple variables can interact with the same data in different ways in Rust. Let's look at an example using an integer in Listing 4-2.
let x = 5;
let y = x;
Listing 4-2: Assigning the integer value of variable x
to y
We can probably guess what this is doing: "bind the value 5
to x
; then make a copy of the value in x
and bind it to y
." We now have two variables, x
and y
, and both equal 5
. This is indeed what is happening, because integers are simple values with a known, fixed size, and these two 5
values are pushed onto the stack.
Now let's look at the String
version:
let s1 = String::from("hello");
let s2 = s1;
This looks very similar, so we might assume that the way it works would be the same: that is, the second line would make a copy of the value in s1
and bind it to s2
. But this isn't quite what happens.
Take a look at Figure 4-1 to see what is happening to String
under the covers. A String
is made up of three parts, shown on the left: a pointer to the memory that holds the contents of the string, a length, and a capacity. This group of data is stored on the stack. On the right is the memory on the heap that holds the contents.
Figure 4-1: Representation in memory of a String
holding the value "hello"
bound to s1
The length is how much memory, in bytes, the contents of the String
are currently using. The capacity is the total amount of memory, in bytes, that the String
has received from the allocator. The difference between length and capacity matters, but not in this context, so for now, it's fine to ignore the capacity.
When we assign s1
to s2
, the String
data is copied, meaning we copy the pointer, the length, and the capacity that are on the stack. We do not copy the data on the heap that the pointer refers to. In other words, the data representation in memory looks like Figure 4-2.
Figure 4-2: Representation in memory of the variable s2
that has a copy of the pointer, length, and capacity of s1
The representation does not look like Figure 4-3, which is what memory would look like if Rust instead copied the heap data as well. If Rust did this, the operation s2 = s1
could be very expensive in terms of runtime performance if the data on the heap were large.
Figure 4-3: Another possibility for what s2 = s1
might do if Rust copied the heap data as well
Earlier, we said that when a variable goes out of scope, Rust automatically calls the drop
function and cleans up the heap memory for that variable. But Figure 4-2 shows both data pointers pointing to the same location. This is a problem: when s2
and s1
go out of scope, they will both try to free the same memory. This is known as a double free error and is one of the memory safety bugs we mentioned previously. Freeing memory twice can lead to memory corruption, which can potentially lead to security vulnerabilities.
To ensure memory safety, after the line let s2 = s1;
, Rust considers s1
as no longer valid. Therefore, Rust doesn't need to free anything when s1
goes out of scope. Check out what happens when you try to use s1
after s2
is created; it won't work:
let s1 = String::from("hello");
let s2 = s1;
println!("{s1}, world!");
You'll get an error like this because Rust prevents you from using the invalidated reference:
error[E0382]: borrow of moved value: `s1`
--> src/main.rs:5:28
|
2 | let s1 = String::from("hello");
| -- move occurs because `s1` has type `String`, which
does not implement the `Copy` trait
3 | let s2 = s1;
| -- value moved here
4 |
5 | println!("{s1}, world!");
| ^^ value borrowed here after move
If you've heard the terms shallow copy and deep copy while working with other languages, the concept of copying the pointer, length, and capacity without copying the data probably sounds like making a shallow copy. But because Rust also invalidates the first variable, instead of being called a shallow copy, it's known as a move. In this example, we would say that s1
was moved into s2
. So, what actually happens is shown in Figure 4-4.
Figure 4-4: Representation in memory after s1
has been invalidated
That solves our problem! With only s2
valid, when it goes out of scope it alone will free the memory, and we're done.
In addition, there's a design choice that's implied by this: Rust will never automatically create "deep" copies of your data. Therefore, any automatic copying can be assumed to be inexpensive in terms of runtime performance.