8.xChapter 8 summary and quiz

Last updated June 12, 2026

The chapter the course was named after is behind you. If it felt smaller than its reputation, that was the plan: seven short lessons, each one move on the same diagram. Here's the whole picture at once, then a quiz that makes you play it.

Quick review

Memory that a program requests at runtime must be given back exactly once; too early is a use-after-free, twice is a double free, never is a leak. The industry's three answers: trust the programmer (C/C++; fast and dangerous), pay a garbage collector (Java and friends; safe, with runtime cost and unpredictable pauses), or Rust's third way, ownership: compile-time rules that let the compiler write every give-it-back into the program before it runs. The rules fit in a breath: every value has an owner; one owner at a time; when the owner goes out of scope, the value is dropped.

The floor plan underneath: the stack is a fixed-size column of memory run with plate-stack discipline, holding one frame per unreturned function call (return bookmark, parameters, locals). Pushing and popping frames is just moving a marker, which is why stack allocation is nearly free, why locals never needed cleanup ceremony, and why deep recursion ends in a stack overflow. The stack's price is rigidity: every size known at compile time. Runtime-sized data lives on the heap, where the allocator hands out blocks on request. A String straddles both: a fixed-size handle in the frame (address, length, capacity) owning a heap block of text.

Dropped means the value's memory is given back at the owner's closing brace: a fixed place in the program, not a background process. Cleanup you can point at is the whole trick; it's how Rust gets collector-grade safety with zero collector.

Moves are what = means for owning types: the handle transfers, the old variable is dead, and using it is error[E0382], whose anatomy you now read fluently (move-because-the-type-isn't-Copy, value moved here, borrowed here after move, and a .clone() diff if the compiler thinks it'd help). One owner at a time makes the double free unwritable. Copy types opt out because they live whole in their boxes (all integers, floats, bool, char, unit, all-Copy tuples, and &str, which copies only the view): for them = copies and both variables live. Functions follow the same physics: passing a String gives it, the parameter drops it on return, and the compiler's own note says which parameter "takes ownership of the value"; returning a value gives it back. Functions that only read text take &str; functions that keep it take String; and + consumes its left side because it owns, grows, and hands onward that very block. When two independent values is the genuine requirement, .clone() buys the deep copy with visible ink: the expensive thing in Rust is never silent, and the silent thing is never expensive.

And one promissory note, now due next chapter: the give-and-take-back tuple dance, the error-silencing clone, and the note "consider changing this parameter type to borrow instead" all point at the same door. You've been pushing values through it with &mut since lesson 1.6. Chapter 9 opens it.

Quiz time

Question #1

Three claims, true or false, one sentence of why:

a) When a Rust program assigns one String variable to another, the text is copied to a new heap block. b) A value can be unusable while its variable's name is still in scope. c) Dropping happens when Rust's runtime detects a value is no longer reachable.

Question #2

Compile or not? For each, one sentence.

a)

fn main() {
    let x = 7;
    let y = x;
    println!("{x} {y}");
}

b)

fn main() {
    let tag = String::from("fragile");
    let label = tag;
    println!("{tag}");
}

c)

fn main() {
    let park = String::from("bench");
    let view: &str = &park;
    let second = view;
    println!("{view} {second} {park}");
}

d)

fn main() {
    let s = String::from("inner");
    {
        let t = s;
    }
    println!("{s}");
}

Question #3

Read this error aloud, the way lesson 8.4 did: say which line moved the value, which line used it illegally, and what the compiler's two suggestions (one note, one help) would each mean for the program.

fn main() {
    let recipe = String::from("knead, rest, bake");
    publish(recipe);
    println!("saved: {recipe}");
}

fn publish(text: String) {
    println!("publishing: {text}");
}

error[E0382]: borrow of moved value: `recipe`
 --> src/main.rs:4:23
  |
2 |     let recipe = String::from("knead, rest, bake");
  |         ------ move occurs because `recipe` has type `String`, which does not implement the `Copy` trait
3 |     publish(recipe);
  |             ------ value moved here
4 |     println!("saved: {recipe}");
  |                       ^^^^^^ value borrowed here after move
  |
note: consider changing this parameter type in function `publish` to borrow instead if owning the value isn't necessary
 --> src/main.rs:7:18
  |
7 | fn publish(text: String) {
  |    -------       ^^^^^^ this parameter takes ownership of the value
  |    |
  |    in this function
help: consider cloning the value if the performance cost is acceptable
  |
3 |     publish(recipe.clone());
  |                   ++++++++

Question #4

Bug hunt. This program compiles and works, but a chapter 8 graduate should wince three times. Find the three wasteful or wrong-headed spots and say what each should be:

fn banner(title: String) -> String {
    format!("== {title} ==")
}

fn main() {
    let title = String::from("Daily Report");
    let decorated = banner(title.clone());
    println!("{decorated}");
    println!("{}", title.clone());
}

Question #5

Write a gift-tag program:

• An ask function: takes a prompt as &str, prints it, reads a line (lesson 1.6's recipe), and returns the trimmed input as an owned String. Explain to yourself why the return type must be String and not a view of the input.
• A make_tag function: takes a recipient and a gift as &strs plus a count as u32, and returns a String like To Maria: 3 x teacups (lesson 5.5's tools).
• A with_length function, just to feel this chapter in your fingers: takes the finished tag by value (String) and returns (String, usize), the tag and its length in bytes, give-and-take-back style.
• main wires it together, asks for recipient, gift, and count (parse the count, lesson 5.6), and prints the tag plus its byte length.

A run should look like:

Who is the gift for?
What is the gift?
How many?
To Maria: 3 x teacups
(21 bytes)

use std::io;

fn ask(prompt: &str) -> String {
    println!("{prompt}");
    let mut input = String::new();
    io::stdin()
        .read_line(&mut input)
        .expect("failed to read input");
    String::from(input.trim())
}

fn make_tag(recipient: &str, gift: &str, count: u32) -> String {
    format!("To {recipient}: {count} x {gift}")
}

fn with_length(tag: String) -> (String, usize) {
    let bytes = tag.len();
    (tag, bytes)
}

fn main() {
    let recipient = ask("Who is the gift for?");
    let gift = ask("What is the gift?");
    let count: u32 = ask("How many?").parse().expect("not a number");

    let tag = make_tag(&recipient, &gift, count);
    let (tag, bytes) = with_length(tag);

    println!("{tag}");
    println!("({bytes} bytes)");
}

What's next

Chapter 9 keeps the biggest promise in the course. Every awkward moment in this chapter (the tuple dance, the defensive clone, the function that swallowed your String) dissolves into a single character you've been writing since lesson 1.6: &. References, borrowing, and the famous borrow checker, which you'll find is not a wall but the chapter 8 rules with better manners.