Description
In the section "Ways Variables and Data Interact: Move" after introducing how memory is represented and not represented, there is a paragraph that is setting up the introduction to the move concept.
To ensure memory safety, there’s one more detail to what happens in this situation in Rust. Instead of trying to copy the allocated memory, Rust considers s1 to no longer be valid and, 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:
The clause Instead of trying to copy the allocated memory is uncessary because it implicitly refers to Figure 4-3 and at this point the reader knows that Figure 4-3 does not represent Rust's memory layout for the given code sample. Also, the prior paragraph to the one quoted above redirects the reader's focus back to Figure 4-2 where only the stack data is copied. The rest of this section also illustrates and talks about data copied on the stack (e.g. "instead of being called a shallow copy, it’s known as a move.").
May I suggest the following edit:
To ensure memory safety, there’s one more detail in this situation. Rust considers s1 to no longer be valid and, 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:
I hope this helps prevent others from thinking that the data on the stack is not copied.
As an aside: If I understand correctly, this section is telling me that a copy of s1's data (ptr, len, capacity) is made on the stack and bound to s2 then s1 is invalidated. s1's data is still on the stack but the programmer no longer has access to the s1 variable because it is has been invalidated. If there was let s3 = s2; statement, then there would be three copies of the same data (ptr, len, capacity) on the stack but only one valid variable s3 that the programmer can use.