Values, places, and bindings

Lesson 0.1 showed you a three-line program that did not compile, and — more importantly — showed that you did not doubt it. This lesson replaces the model that failed.

It is the most important lesson on the site. Everything in Parts 2 and 4 is a consequence of what follows.

The official Rust term for this is a place expression — an expression that denotes a location rather than a value. Local variables, struct fields, array elements and *ptr are all place expressions. Nearly no tutorial uses this word, which is a shame, because once you have it, assignment, borrowing and pattern matching stop being three separate topics.

What a move actually does

The word “move” makes people imagine something expensive. It is the opposite.

Take let s = String::from("hello"). A String is a three-word struct:

place `s`  ┌──────────────┬────────┬──────────┐
(on stack) │ ptr          │ len: 5 │ cap: 5   │
           └──────┬───────┴────────┴──────────┘
                  │
                  ▼
heap       ┌───┬───┬───┬───┬───┐
           │ h │ e │ l │ l │ o │
           └───┴───┴───┴───┴───┘

Now let t = s;. Here is the whole operation:

place `s`  ┌ ─ ─ ─ ─ ─ ─ ─┬─ ─ ─ ─ ┬─ ─ ─ ─ ─ ┐
(dead)       (bytes may still be here, but the
           └ ─ compiler will not let you read them) ┘

place `t`  ┌──────────────┬────────┬──────────┐
(on stack) │ ptr          │ len: 5 │ cap: 5   │
           └──────┬───────┴────────┴──────────┘
                  │
                  ▼
heap       ┌───┬───┬───┬───┬───┐   ← untouched, never copied
           │ h │ e │ l │ l │ o │
           └───┴───┴───┴───┴───┘

Three words of memcpy, and a note in the compiler’s records that s is now dead. The heap buffer is not copied, not reference-counted, not scanned. In optimised builds the copy itself usually disappears — the compiler just decides both names refer to the same stack slot.

A move is mostly a compile-time bookkeeping act. That is why Rust can afford to make it the default.

The answer is Drop, and it is worth stating plainly because it is the load-bearing reason for the entire ownership system: when a place goes out of scope, the value in it is destroyed, and for a String that means freeing the heap buffer. If both s and t were live, both would try to free the same buffer at the end of the function. That is a double free, and it is one of the classic memory-safety bugs.

Rust’s answer is not to detect double frees. It is to make it impossible to have two owners in the first place. One value, one place, one free.

mut is about the binding, not the value

Second piece of unlearning, and this one trips up people who are otherwise doing fine.

Read that table before the explanation below it. The rows are constructed so that exactly one thing changes at a time; that is what makes the critical feature visible.

Now the explanation. mut is a property of the path you use to reach a value, not of the value itself. The same String can be reachable through a &mut in one part of a program and a & in another. Nothing is stamped onto the bytes.

This is why the following is not a contradiction:

let s = String::from("hi");   // s is not mutable
let mut s = s;                 // moved into a mutable place
s.push('!');                   // fine

The value never changed. It moved from an immutable place to a mutable one.

fn main() {
    let x = 5;
    {
        let x = x * 2;
        println!("inner: {x}");
    }
    println!("outer: {x}");
}

inner: 10
outer: 5

Ownership is a tree

One more consequence, and then we stop.

Because every value has exactly one owning place, and places can be nested (a struct field is a place inside a struct’s place), ownership in a Rust program forms a tree. Not a graph — a tree.

struct Server {
    name: String,          // the Server owns this String
    routes: Vec<Route>,    // and this Vec, which owns each Route
}

Dropping the Server drops the String and the Vec; dropping the Vec drops every Route. The whole subtree is released, deterministically, in a defined order, with no runtime bookkeeping at all.

This is the real reason Rust does not need a garbage collector, and it is worth being precise about it in conversation. It is not that Rust is “careful with memory”. It is that the ownership structure is a tree known at compile time, so the compiler can insert the frees itself.

The natural follow-up question — what if my data really is a graph? — is correct, important, and deliberately deferred to 2.6. Rust’s answer is Rc, RefCell and friends, and they exist precisely because the tree model is not always enough. Keep the question.

What you should now be able to say

• A let binding creates a place that owns a value.
• let t = s moves: a shallow copy of the value’s representation, plus a compile-time mark that s is dead. The heap is untouched.
• Moves are cheap. The expense people imagine is Clone, which is a different operation.
• mut describes a place, not a value.
• Shadowing makes a new place; mutation writes into an existing one.
• Ownership forms a tree, which is what makes deterministic destruction possible without a collector.

Next: 1.2 — Stack, heap, and fat pointers, where we look at what is actually in these places.