21.xChapter 21 summary and quiz

Last updated June 13, 2026

This chapter named a pattern you'd been using all along and added three deliberate tools to it. Review, then a capstone that combines them.

Quick review

A smart pointer is a value that owns data and adds behavior, you've used String and Vec as smart pointers since chapter 1 (21.1). Two traits make one: Deref (reach through it like a pointer) and Drop (clean up when it dies).

Box<T> puts a single value on the heap with one owner (21.2). Its essential use is recursive types: enum List { Cons(i32, Box<List>), Nil } compiles where the un-boxed version has "infinite size," because a Box is a fixed-size pointer. Also used for trait objects and large moves.

Deref defines * for a type, returning a reference to its inner value (21.3). Deref coercion auto-inserts deref calls so &Box<String> works where &str is wanted, which is exactly why &String works as &str (the chapter-9 mystery, solved).

Drop runs cleanup code when a value goes out of scope (21.4); values drop in reverse declaration order; drop early with std::mem::drop(v) (never v.drop()). This is RAII: resource lifetime tied to value lifetime, the reason Rust needs neither manual frees nor a garbage collector.

Rc<T> gives shared ownership by reference counting (21.5): Rc::clone bumps a count cheaply (no deep copy), and the value frees when the last owner drops. Shared but immutable, and single-threaded only (Arc for threads, chapter 22).

RefCell<T> moves the borrow check to run time, enabling interior mutability, mutation through a shared reference via borrow()/borrow_mut(), panicking (BorrowMutError) on violations instead of failing to compile (21.6). Rc<RefCell<T>> combines shared ownership with shared mutability.

Reference cycles of strong Rcs leak memory (a safe bug, wasteful but not corrupting); Weak<T> breaks them with non-owning references read via upgrade() (21.7).

Quiz time

Question #1

Why must a recursive type like a cons list put its recursive field behind a Box (or Rc)?

Question #2

Rc<T> and RefCell<T> each give up something that &/&mut provide. What, and why combine them?

Question #3

Predict the output:

struct Loud(i32);
impl Drop for Loud {
    fn drop(&mut self) { println!("drop {}", self.0); }
}
fn main() {
    let a = Loud(1);
    let b = Loud(2);
    drop(a);
    println!("end of main");
}

drop 1
end of main
drop 2

Question #4

A tree node holds Rc pointers to its children and you want each child to also reference its parent. Why should the parent-pointer be a Weak, not an Rc?

Chapter capstone

Build a small shared, mutable counter that several handles can increment, then print the final value. This exercises Rc (shared ownership) and RefCell (interior mutability) together, the combination you'll meet constantly.

Write a program that creates a counter starting at 0, makes three handles to it, increments through each handle a different number of times (1, 2, and 3), and prints the total.

use std::rc::Rc;
use std::cell::RefCell;

fn main() {
    let counter = Rc::new(RefCell::new(0));

    let h1 = Rc::clone(&counter);
    let h2 = Rc::clone(&counter);
    let h3 = Rc::clone(&counter);

    *h1.borrow_mut() += 1;                 // +1
    for _ in 0..2 { *h2.borrow_mut() += 1; }   // +2
    for _ in 0..3 { *h3.borrow_mut() += 1; }   // +3

    println!("count: {}", counter.borrow());
    println!("owners: {}", Rc::strong_count(&counter));
}

count: 6
owners: 4

You can now allocate on the heap deliberately, share ownership, mutate shared data, and clean up automatically, the full memory toolkit for single-threaded programs. Chapter 22 takes the leap that no other beginner course makes this gently: running code on multiple threads at once, where Rc becomes Arc, RefCell becomes Mutex, and the data race the borrow checker warned about back in chapter 9 becomes the central enemy that Rust, uniquely, makes impossible to compile.