Mention that the left-hand side of an assignment is dropped

[MariusDoe]

• I have searched open and closed issues and pull requests for duplicates, using these search terms:
  • drop
  • dropped
  • assign
  • assigned
  • assignment
• I have checked the latest main branch to see if this has already been fixed, in these files:
  • https://github.com/rust-lang/book/blob/04bc1396bb857f35b5dda1d773c9571e1f253304/src/ch04-01-what-is-ownership.md
  • https://github.com/rust-lang/book/blob/04bc1396bb857f35b5dda1d773c9571e1f253304/src/ch15-03-drop.md

URL to the section(s) of the book with this problem: see above

Description of the problem:

• The book explains that a value is dropped, when its owner goes out of scope (in the Ownership Rules section of chapter 4.1), but it does not explain that they are also dropped when its owner gets assigned a different value. These are the currently listed rules:
  

  book/src/ch04-01-what-is-ownership.md

  Lines 86 to 93 in 04bc139

  	### Ownership Rules
  	First, let’s take a look at the ownership rules. Keep these rules in mind as we
  	work through the examples that illustrate them:
  	* Each value in Rust has an *owner*.
  	* There can only be one owner at a time.
  	* When the owner goes out of scope, the value will be dropped.

• Chapter 15.3 explains the Drop trait (and shows the reverse drop order of multiple let bindings with some example code), but also does not mention the effect of an assignment.
• To find out about this behavior or to find out when (if at all) values that are overwritten via assignment are dropped, one currently has to look into the reference chapter for destructors (version at issue creation), it states:

  Assignment also runs the destructor of its left-hand operand, if it's initialized.

Suggested fix:

• In chapter 4.1, mention that a reassignment of the owner of a value also drops that value.
  For example, the last bullet point of the Ownership Rules may be replaced with (added parts marked):

  • When the owner goes out of scope or is assigned a different value, the (original) value will be dropped.

  Or another rule may be added:

  • When the owner is assigned a different value, the original value will be dropped.

• In chapter 4.1, add an explaining example of the behavior, for example between these two paragraphs. The example might look like this:

  {
      let mut s = String::from("hello");
      // do stuff with s
      s = String::from("world"); // s gets reassigned, so the "hello" String is dropped here
      // do stuff with s
  }   // this scope is now over, and the "world" String will be dropped

• In chapter 15.3, add an example that shows the drop behavior of an assignment, by using the CustomSmartPointer already defined in the chapter. Alternatively, extend the first example in the chapter with the assignment behavior (might be too much in a single example?).

[chriskrycho]

I spent some time looking at and thinking about how to solve this today, but as noted in a comment on the PR I opened, I have concluded that we should not try to cover this in the book—it’s far too subtle a thing for Ch. 4, and in my judgment probably even too subtle for the discussion in Ch. 15. As I note there: the fact that it is not a thing I have ever had to think about explicitly in writing a decent bit of Rust in the last 9 years—and that I got the details wrong but have never been bitten by that is indicative that it's a fairly advanced but also a fairly niche topic. I’m going to basically punt it to the Reference and documents at a similar level.

[MariusDoe]

Hey @chriskrycho, thank you for looking into this! I completely understand your point about this being a subtle thing. But I noticed that your PR discusses shadowing, not assignment to an existing variable (shadowing is interesting too, I didn't know that the original variable lives on after it was shadowed). To clarify, in this issue, I was talking about the latter. To use your example from the PR:

fn main() {
    let mut s = String::from("hello");  // let mut instead of let here
    s = String::from("ahoy");           // assignment instead of let here

    println!("{s}, world!");
}

In this case, the "hello" String does go out of scope (or gets dropped, rather) in the second line of the function body (playground).

So my question is: does your point about the subtlety apply to assignment, too? If it does, I am happy to keep this issue closed :)

[chriskrycho]

Ah! I am going to chalk that one up to day-after-a-hard-running-race brain; I totally misremembered what you were discussing here. This is indeed much less subtle and I’ll see about adding something like that PR but with this, which I think is totally reasonable. Sorry about the confusion on my end! 😅

[MariusDoe]

No problem, I totally understand 😅

Thanks for creating the new PR, I'll have a look at it :)