The Three Ownership Rules

21 min read

Ownership is the mechanism Rust uses to manage memory without a garbage collector. Instead of a runtime that periodically scans for unreachable objects (the JavaScript model), Rust decides at compile time exactly when each value is freed. The whole system rests on three short rules, and this page is about those rules and nothing more.

Quick Overview

In Rust, every value has exactly one owner; ownership moves when you assign the value or pass it to a function; and when the owner goes out of scope, the value is dropped (its memory freed) automatically. There is no new/delete, no free(), and no garbage collector — the compiler tracks ownership and inserts cleanup for you. For a TypeScript/JavaScript developer, the surprising part is not the cleanup (the GC already hides that) but that handing a value to someone else can make your own variable unusable.

Note: This page covers the rules themselves and the move that happens on assignment and function calls. Borrowing (&), which lets you lend access without giving up ownership, is the subject of borrowing.md. The stack/heap distinction that explains why moves matter lives in stack-heap.md.

TypeScript/JavaScript Example

In JavaScript and TypeScript you never think about who “owns” a value. You create objects, pass them around, and the garbage collector (GC) frees them whenever it decides nothing can reach them anymore.

1
// TypeScript/JavaScript: values are shared freely, GC cleans up "eventually"
2
function archiveOrder(orderId: string): void {
3
  console.log(`Archiving ${orderId}`);
4
}
5

6
let orderId = "ORD-2026-0531";
7
let archived = orderId; // both names now refer to the same string value
8

9
console.log(orderId); // "ORD-2026-0531" — still usable
10
console.log(archived); // "ORD-2026-0531"
11

12
archiveOrder(orderId); // pass it to a function...
13
console.log(orderId); // still usable afterward — nothing was "consumed"
14

15
// When `orderId` and `archived` become unreachable, the GC frees the memory
16
// at some unspecified later time. You never decide when.

Key points:

Assigning archived = orderId makes a second handle to the same data (for objects/arrays it is a shared reference; for primitives like strings it is a copy, but either way the original stays valid).
Passing a value to a function does not invalidate the caller’s variable.
Cleanup timing is non-deterministic — the GC runs when it wants.

Rust Equivalent

Rust enforces a stricter discipline. The same let archived = order_id; moves ownership, and the original binding becomes unusable.

1
fn print_receipt(id: String) {
2
    println!("Receipt: {id}");
3
} // `id` dropped here, its heap buffer freed
4

5
fn main() {
6
    // ---- Rule 1 & 2: single owner, move on assignment ----
7
    let order_id = String::from("ORD-2026-0531");
8
    let archived = order_id; // value MOVES; `order_id` is no longer valid
9
    println!("Archived order: {archived}");
10

11
    // ---- Rule 3: drop at end of scope ----
12
    {
13
        let temp = String::from("temporary buffer");
14
        println!("Inside block: {temp}");
15
    } // `temp` goes out of scope here -> its heap buffer is freed
16

17
    // ---- move into a function ----
18
    let receipt = String::from("RCPT-9001");
19
    print_receipt(receipt); // ownership moves into print_receipt
20
    // println!("{receipt}"); // would not compile: value moved
21

22
    // ---- Copy types are duplicated, not moved ----
23
    let total = 42_u32;
24
    let copy = total; // u32 is Copy: bitwise copy, both stay valid
25
    println!("total={total}, copy={copy}");
26
}

Output:

1
Archived order: ORD-2026-0531
2
Inside block: temporary buffer
3
Receipt: RCPT-9001
4
total=42, copy=42

Key points:

let archived = order_id; moves ownership; order_id can no longer be used.
Passing receipt to print_receipt moves it into the function.
temp is freed precisely at the closing } of its block — deterministically.
Small stack-only types like u32 are Copy, so let copy = total; duplicates instead of moving. (Copy vs Clone is the topic of move-copy-clone.md.)

Detailed Explanation

The Rust Book states the three rules verbatim:

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 is dropped.

Let’s take them one at a time, line by line, and contrast each with what TypeScript/JavaScript does.

Rule 1 — Each value has an owner

A value is a piece of data (a String, a Vec, a struct, a number). A variable (more precisely, a binding) is the name that owns it.

1
let order_id = String::from("ORD-2026-0531");

Here order_id is the owner of the heap-allocated string buffer. Ownership is a property the compiler tracks; it is not stored at runtime and costs nothing. There is no header, no reference count, no GC bookkeeping attached to the value — the compiler simply knows who the owner is at every point in the program.

In JavaScript there is no analogous concept. A value can be reachable through any number of variables and object fields simultaneously, and “who owns it” is a meaningless question because the GC owns everything.

Rule 2 — One owner at a time: the move

This is the rule that bites TypeScript/JavaScript developers. Assigning a value to a new binding transfers ownership rather than copying or aliasing it:

1
let order_id = String::from("ORD-2026-0531");
2
let archived = order_id; // ownership MOVED into `archived`

A String is a three-word value on the stack — a pointer to a heap buffer, a length, and a capacity. The move copies those three words into archived and then invalidates order_id. It does not copy the heap buffer, and it does not create a second valid pointer to the same buffer. If both order_id and archived were allowed to be used, both would try to free the same buffer when they went out of scope — a classic double-free bug. The move rule makes that impossible.

Tip: Read let archived = order_id; as “archived takes over ownership from order_id,” not “archived is a copy of order_id.” After this line, order_id is gone — not empty, not null, just not a thing you can name anymore.

Passing a value to a function is also a move, because the parameter is a new binding:

1
let receipt = String::from("RCPT-9001");
2
print_receipt(receipt); // `receipt` moved into the parameter `id`

After this call, receipt is no longer usable in main — its ownership now belongs to print_receipt, and when that function ends, the value is dropped there.

Why doesn’t this happen with numbers? Types whose data lives entirely on the stack and is cheap to duplicate — integers, floats, bool, char, and tuples of them — implement the Copy trait. For those, let copy = total; makes an independent bitwise copy and leaves the original valid. There is no heap buffer to double-free, so copying is safe. String, Vec<T>, and most structs are not Copy, so they move. See move-copy-clone.md for the full story.

Rule 3 — Dropped at end of scope

When a binding goes out of scope, Rust automatically runs cleanup for the value it owns. For a String or Vec, that means freeing the heap buffer; for a file handle, closing the file; for a lock guard, releasing the lock. This is deterministic and tied to lexical scope:

1
{
2
    let temp = String::from("temporary buffer");
3
    println!("Inside block: {temp}");
4
} // `temp` dropped HERE — exactly at this `}`, every time

You can see this happen by implementing the Drop trait so the value prints when it is cleaned up:

1
struct Connection {
2
    label: &'static str,
3
}
4

5
impl Drop for Connection {
6
    fn drop(&mut self) {
7
        println!("Closing connection: {}", self.label);
8
    }
9
}
10

11
fn main() {
12
    println!("Start of main");
13
    let first = Connection { label: "first" };
14
    let second = Connection { label: "second" };
15
    println!("Opened {} and {}", first.label, second.label);
16

17
    {
18
        let inner = Connection { label: "inner-block" };
19
        println!("Inside inner block with {}", inner.label);
20
    } // `inner` dropped here
21

22
    println!("Back in main");
23
} // `second` then `first` dropped here (reverse declaration order)

Output:

1
Start of main
2
Opened first and second
3
Inside inner block with inner-block
4
Closing connection: inner-block
5
Back in main
6
Closing connection: second
7
Closing connection: first

Two things to notice. First, inner is dropped at the inner }, before Back in main prints — cleanup is scope-bound, not deferred to the end of the program. Second, within a scope, values are dropped in reverse order of declaration (second before first), like unwinding a stack. The mechanics of Drop and this ordering are explored in depth in drop-trait.md; here the point is simply that Rule 3 frees memory automatically, at a moment you can predict by reading the code.

This is the polar opposite of JavaScript. The JS engine’s GC frees objects at an unspecified time after they become unreachable, and FinalizationRegistry callbacks are explicitly documented as offering no timing guarantees and may never run at all. Rust gives you precise, source-visible cleanup with zero runtime tracking.

What “move” actually invalidates

A natural question: if you give a value away, how do you keep using your data? Three answers, in increasing order of preference:

Get it back. A function can take ownership and return it (possibly alongside other results):

1
fn measure(s: String) -> (String, usize) {
2
    let len = s.len();
3
    (s, len) // hand the String back to the caller
4
}
5

6
fn main() {
7
    let s = String::from("ownership");
8
    let (s, len) = measure(s); // re-bind `s` from the returned tuple
9
    println!("'{s}' has length {len}");
10
}

Output: 'ownership' has length 9

Clone it. Make an explicit, independent deep copy so each binding owns its own data:

1
let original = String::from("config.toml");
2
let backup = original.clone(); // explicit, potentially expensive deep copy
3
println!("original = {original}");
4
println!("backup   = {backup}");

Borrow it (best). Lend a reference so no move happens at all — the caller keeps ownership:

1
fn char_count(s: &str) -> usize {
2
    s.chars().count()
3
}
4

5
let path = String::from("/etc/hosts");
6
let length = char_count(&path); // pass a reference; no move
7
println!("'{path}' has {length} chars"); // `path` still owned here

Borrowing is usually the right tool and is the subject of the next page. Returning ownership and cloning are covered above so you understand the alternatives the compiler keeps suggesting.

Key Differences

Concept	TypeScript / JavaScript	Rust
Who frees memory	Garbage collector, at an unspecified time	The compiler, deterministically at scope exit
Assignment (`b = a`)	New handle/reference (or value copy for primitives); `a` stays valid	Move: ownership transfers; `a` becomes unusable (unless the type is `Copy`)
Passing to a function	Caller’s variable stays valid	Argument is moved in; caller’s variable becomes unusable (unless `Copy` or you pass a reference)
Number of live references to one value	Unlimited	Exactly one owner (plus borrows, governed separately)
Cleanup timing	Non-deterministic; `FinalizationRegistry` gives no guarantees	Deterministic, at the closing `}` of the owner’s scope
Runtime cost	GC pauses, allocation headers, tracing	Zero — ownership is a compile-time-only concept
Double-free / use-after-free	Not possible (GC), but memory leaks via retained references are	Prevented at compile time by the move rule

The core mental shift: in JavaScript, naming a value more times keeps it alive longer. In Rust, naming a value a second time (by assignment or passing it) usually consumes the first name. You move the responsibility of freeing the value, and only one binding can hold that responsibility at a time.

Note: “Move” in Rust is a compile-time bookkeeping operation. At runtime, moving a String is just copying three machine words (pointer, length, capacity); the heap buffer is untouched. The compiler then refuses to let you use the old binding. So a move is cheap and safe — you are not paying for a deep copy, and you cannot accidentally alias the buffer.

Common Pitfalls

Pitfall 1: Using a value after it was moved by assignment

This is the first error nearly every newcomer hits.

1
fn main() {
2
    let order_id = String::from("ORD-2026-0531");
3
    let archived = order_id;
4
    println!("{order_id}"); // does not compile (error[E0382]): use after move
5
    println!("{archived}");
6
}

The compiler is precise and even suggests the fix:

1
error[E0382]: borrow of moved value: `order_id`
2
 --> src/main.rs:4:16
3
  |
4
2 |     let order_id = String::from("ORD-2026-0531");
5
  |         -------- move occurs because `order_id` has type `String`, which does not implement the `Copy` trait
6
3 |     let archived = order_id;
7
  |                    -------- value moved here
8
4 |     println!("{order_id}"); // does not compile (error[E0382]): use after move
9
  |                ^^^^^^^^ value borrowed here after move
10
  |
11
  = note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
12
help: consider cloning the value if the performance cost is acceptable
13
  |
14
3 |     let archived = order_id.clone();
15
  |                            ++++++++

Fix: clone if you genuinely need two independent owners (order_id.clone()), or borrow if you only need to read it. The phrase “does not implement the Copy trait” is the compiler telling you why this was a move rather than a copy.

Pitfall 2: Using a value after passing it to a function

Coming from JavaScript, you expect the caller’s variable to survive a function call. It does not, if the value was moved in.

1
fn print_receipt(id: String) {
2
    println!("Receipt: {id}");
3
}
4

5
fn main() {
6
    let receipt = String::from("RCPT-9001");
7
    print_receipt(receipt);
8
    println!("Still have: {receipt}"); // does not compile (error[E0382]): moved into function
9
}

Real compiler output (abbreviated — note the targeted hint about the parameter type):

1
error[E0382]: borrow of moved value: `receipt`
2
 --> src/main.rs:8:28
3
  |
4
6 |     let receipt = String::from("RCPT-9001");
5
  |         ------- move occurs because `receipt` has type `String`, which does not implement the `Copy` trait
6
7 |     print_receipt(receipt);
7
  |                   ------- value moved here
8
8 |     println!("Still have: {receipt}"); // does not compile (error[E0382]): moved into function
9
  |                            ^^^^^^^ value borrowed here after move
10
  |
11
note: consider changing this parameter type in function `print_receipt` to borrow instead if owning the value isn't necessary
12
 --> src/main.rs:1:22
13
  |
14
1 | fn print_receipt(id: String) {
15
  |    -------------     ^^^^^^ this parameter takes ownership of the value
16
... (rustc continues with a "help: consider cloning the value" suggestion)

Fix: if the function only needs to read the value, take &str/&String instead of String, so the call borrows rather than moves. (That is exactly what borrowing.md teaches.)

Pitfall 3: Moving a value inside a loop

A move that is fine once becomes an error when it repeats:

1
fn print_banner(text: String) {
2
    println!("{text}");
3
}
4

5
fn main() {
6
    let banner = String::from("=== Report ===");
7
    for _ in 0..3 {
8
        print_banner(banner); // does not compile (error[E0382]): moved in previous iteration
9
    }
10
}

The compiler specifically calls out the loop (output abbreviated):

1
error[E0382]: use of moved value: `banner`
2
 --> src/main.rs:8:22
3
  |
4
6 |     let banner = String::from("=== Report ===");
5
  |         ------ move occurs because `banner` has type `String`, which does not implement the `Copy` trait
6
7 |     for _ in 0..3 {
7
  |     ------------- inside of this loop
8
8 |         print_banner(banner); // does not compile (error[E0382]): moved in previous iteration
9
  |                      ^^^^^^ value moved here, in previous iteration of loop
10
... (rustc continues with "help: consider moving the expression out of the loop" and "help: consider cloning the value" suggestions)

Fix: pass a borrow (print_banner(&banner) with the parameter typed &str), or .clone() inside the loop if each iteration truly needs its own owned copy.

Pitfall 4: Partial moves out of a struct

Moving one field out of a struct leaves the struct only partially valid: you can still read the fields that were not moved, but you can no longer use the struct as a whole.

1
#[derive(Debug)]
2
struct User {
3
    name: String,
4
    email: String,
5
}
6

7
fn main() {
8
    let user = User {
9
        name: String::from("Grace"),
10
        email: String::from("grace@example.com"),
11
    };
12
    let name = user.name; // moves the `name` field out
13
    println!("{}", user.email); // this field is still readable
14
    println!("{:?}", user);     // does not compile (error[E0382]): partial move
15
    println!("{name}");
16
}

Real output:

1
error[E0382]: borrow of partially moved value: `user`
2
  --> src/main.rs:14:22
3
   |
4
12 |     let name = user.name; // moves the `name` field out
5
   |                --------- value partially moved here
6
13 |     println!("{}", user.email); // this field is still readable
7
14 |     println!("{:?}", user);     // does not compile (error[E0382]): partial move
8
   |                      ^^^^ value borrowed here after partial move
9
   |
10
   = note: partial move occurs because `user.name` has type `String`, which does not implement the `Copy` trait

Fix: clone the field you want to take (let name = user.name.clone();), or borrow it (let name = &user.name;), so the struct stays whole.

Best Practices

Borrow by default; move only when you mean to give the value away. If a function just reads or inspects data, take &T (or &str/&[T]). Reserve owned parameters (String, Vec<T>) for functions that store, consume, or transform the value into something they return. This single habit eliminates most E0382 errors.
Reach for .clone() deliberately, not reflexively. The compiler’s “consider cloning” hint is a convenient escape hatch, but a clone is a real allocation and copy. When you find yourself sprinkling .clone() to silence the borrow checker, pause and ask whether a borrow would do — that is usually the idiomatic answer.
Let scope drive cleanup. Don’t look for a free, dispose, or close to call manually. Structure your code so a value’s scope matches its lifetime, and Rule 3 frees it at the right moment. If you need a value gone early, that is what std::mem::drop(value) is for (covered in drop-trait.md).
Return ownership instead of mutating shared state. Where JavaScript code might push into a shared array passed by reference, idiomatic Rust often takes ownership of a value, transforms it, and returns the new owner — a clear, linear flow of who owns what.
Name the move when reading code. When you see let b = a; or f(a), train yourself to ask “is a Copy? If not, a is gone after this line.” This makes ownership errors obvious before the compiler points them out.

Real-World Example

A common production scenario: an upload pipeline that receives raw bytes from a client, validates and parses them, and produces a stored document. Ownership makes the stages explicit — the raw bytes have exactly one owner at each step, and once they are parsed, the original buffer is consumed and cannot be accidentally reused.

1
/// A raw upload received from a client.
2
struct Upload {
3
    filename: String,
4
    bytes: Vec<u8>,
5
}
6

7
/// A validated, parsed document ready to store.
8
struct Document {
9
    filename: String,
10
    line_count: usize,
11
}
12

13
/// Consumes the `Upload` (takes ownership) and hands back a `Document`.
14
/// Because `upload` is moved in, the caller can no longer use it afterward —
15
/// the type system guarantees the raw bytes have exactly one owner per stage.
16
fn parse(upload: Upload) -> Result<Document, String> {
17
    let text = String::from_utf8(upload.bytes)
18
        .map_err(|_| format!("{} is not valid UTF-8", upload.filename))?;
19
    let line_count = text.lines().count();
20
    Ok(Document {
21
        filename: upload.filename, // move the String out of `upload`
22
        line_count,
23
    })
24
} // `text` is dropped here; any unused bytes are freed automatically
25

26
fn main() {
27
    let upload = Upload {
28
        filename: String::from("notes.txt"),
29
        bytes: b"first line\nsecond line\nthird line".to_vec(),
30
    };
31

32
    // Ownership of `upload` moves into `parse`; we get a `Document` back.
33
    match parse(upload) {
34
        Ok(doc) => println!("Stored {} ({} lines)", doc.filename, doc.line_count),
35
        Err(e) => eprintln!("Rejected upload: {e}"),
36
    }
37
    // `upload` is gone here — referencing it would not compile.
38
}

Output:

1
Stored notes.txt (3 lines)

Why this is idiomatic:

parse takes upload by value because it genuinely consumes it — once parsed, the raw bytes are no longer meaningful, and the type system enforces that nobody touches the stale upload.
upload.filename is moved (not cloned) into the new Document, reusing the existing allocation rather than copying the string.
When parse returns the Document, ownership flows to the match arm, and the Document is dropped at the end of that arm — no manual cleanup, no leak.
The compiler would reject any attempt to use upload after the parse(upload) call, catching a whole class of “I accidentally reused the consumed input” bugs that a JavaScript reviewer would have to spot by eye.

Exercises

Exercise 1

Difficulty: Easy

Objective: Recognize a use-after-move and fix it with a clone.

Instructions: The following code does not compile because username is moved into greet and then used again. Make it compile while still logging the username and greeting with it. Do not change the signature of greet.

1
fn greet(name: String) {
2
    println!("Welcome, {name}!");
3
}
4

5
fn main() {
6
    let username = String::from("ada_lovelace");
7
    greet(username);
8
    println!("Logging in: {username}"); // does not compile (error[E0382])
9
}

Solution

Clone before moving so each call has its own owned String, and log first for clarity:

1
fn greet(name: String) {
2
    println!("Welcome, {name}!");
3
}
4

5
fn main() {
6
    let username = String::from("ada_lovelace");
7
    let display = username.clone(); // clone so both names own data
8
    println!("Logging in: {username}");
9
    greet(display); // move the clone into greet
10
}

Output:

1
Logging in: ada_lovelace
2
Welcome, ada_lovelace!

A borrow (fn greet(name: &str)) would be even better here, but the exercise fixed the signature — so cloning is the right tool. You’ll learn the borrow version in borrowing.md.

Exercise 2

Difficulty: Medium

Objective: Use the “give it away, get it back” pattern to keep working with a value after a function consumes it.

Instructions: Write a function append_event that takes ownership of a String log and an event name (&str), appends " <event>" to the log, and returns the updated String so the caller can keep using it. Call it twice in main to build up a log, then print it. Starter:

1
fn main() {
2
    let mut log = String::from("event:");
3
    log = append_event(log, "login");
4
    log = append_event(log, "click");
5
    println!("{log}"); // should print: event: login click
6
}
7

8
fn append_event(/* ??? */) -> String {
9
    // TODO
10
}

Solution

1
fn main() {
2
    let mut log = String::from("event:");
3
    log = append_event(log, "login"); // give it away, get the updated one back
4
    log = append_event(log, "click");
5
    println!("{log}");
6
}
7

8
fn append_event(mut log: String, event: &str) -> String {
9
    log.push(' ');
10
    log.push_str(event);
11
    log // return ownership to the caller
12
}

Output:

1
event: login click

Note the mut log: String parameter: the binding takes ownership and is allowed to mutate the value it owns, then hands the same allocation back. No clone, no extra allocation per call.

Exercise 3

Difficulty: Medium/Hard

Objective: Demonstrate that Rule 3 (drop at end of scope) is deterministic and predict the cleanup order.

Instructions: Define a Timer struct holding a name: String and implement Drop for it so that dropping prints [<name>] finished, cleaning up. In main, create a Timer named "handle_request", then in an inner block create a second Timer named "db_query" and print Running query... inside that block. After the block, print Sending response.... Before running it, write down the order in which the two messages will print, then confirm.

Solution

1
struct Timer {
2
    name: String,
3
}
4

5
impl Drop for Timer {
6
    fn drop(&mut self) {
7
        println!("[{}] finished, cleaning up", self.name);
8
    }
9
}
10

11
fn main() {
12
    println!("Program start");
13
    let _request = Timer { name: String::from("handle_request") };
14
    {
15
        let _db = Timer { name: String::from("db_query") };
16
        println!("Running query...");
17
    } // _db dropped here — at the end of the inner block
18
    println!("Sending response...");
19
} // _request dropped here — at the end of main

Output:

1
Program start
2
Running query...
3
[db_query] finished, cleaning up
4
Sending response...
5
[handle_request] finished, cleaning up

The inner db_query timer is cleaned up the instant its block ends, before Sending response... prints — that is Rule 3 in action. The outer handle_request timer survives until the end of main. This deterministic, scope-bound cleanup is the foundation of RAII patterns like database transactions and lock guards, explored in drop-trait.md.

Note: The bindings are named with a leading underscore (_request, _db) so the compiler doesn’t warn that they’re “unused” — they exist only for their drop side effect, which is a perfectly legitimate use.

The Three Ownership Rules

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Rule 1 — Each value has an owner

Rule 2 — One owner at a time: the move

Rule 3 — Dropped at end of scope

What “move” actually invalidates

Key Differences

Common Pitfalls

Pitfall 1: Using a value after it was moved by assignment

Pitfall 2: Using a value after passing it to a function

Pitfall 3: Moving a value inside a loop

Pitfall 4: Partial moves out of a struct

Best Practices

Real-World Example

Further Reading

Official Documentation

Exercises

Exercise 1

Exercise 2

Exercise 3

The Three Ownership Rules

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

Rule 1 — Each value has an owner

Rule 2 — One owner at a time: the move

Rule 3 — Dropped at end of scope

What “move” actually invalidates

Key Differences

Common Pitfalls

Pitfall 1: Using a value after it was moved by assignment

Pitfall 2: Using a value after passing it to a function

Pitfall 3: Moving a value inside a loop

Pitfall 4: Partial moves out of a struct

Best Practices

Real-World Example

Further Reading

Official Documentation

Related Sections in This Guide

Exercises

Exercise 1

Exercise 2

Exercise 3