Ownership

Overview

Ownership is the foundational concept in Rust's approach to memory safety. Where languages like Java and Go rely on a runtime garbage collector, and languages like C and C++ rely on the programmer to manually allocate and free memory, Rust takes a third path: a set of compile-time rules that the compiler enforces statically, with zero runtime cost.

The ownership system is not a library feature or an optional mode. It is woven into the language at every level — from how variables are bound, to how functions accept arguments, to how values are cleaned up when they go out of scope. Understanding ownership is not just useful for writing Rust; it is understanding Rust.

The Three Rules

The ownership system can be distilled into three rules. Every interaction with memory in Rust is governed by these rules, and the compiler rejects any program that violates them.

1. Each value has exactly one owner

Every value in Rust is "owned" by a variable. There is no shared ownership by default — when you assign a value to a variable, that variable is its sole owner. This might sound restrictive, but it is precisely this restriction that makes the rest of the system possible.

let s1 = String::from("hello");  // s1 owns this String
let s2 = s1;                       // ownership MOVES to s2
// println!("{}", s1);             // ← compile error: s1 is no longer valid
println!("{}", s2);               // ✓ s2 is the owner

2. Ownership can be transferred (moved)

When you pass a value to a function, assign it to another variable, or return it from a function, ownership moves. The previous owner can no longer use the value. This is not a deep copy — the bits stay exactly where they were. Only the compiler's understanding of who is responsible for those bits changes.

fn take_ownership(s: String) {
    println!("I own: {s}");
}   // s is dropped here — memory freed

fn main() {
    let greeting = String::from("kia ora");
    take_ownership(greeting);         // greeting moves into the function
    // greeting is now invalid here
}

3. When the owner goes out of scope, the value is dropped

Rust automatically calls drop on a value when its owner leaves scope. This is deterministic — you know exactly when memory is freed, files are closed, and locks are released. There is no finalizer queue, no GC pause, no ambiguity.

{
    let data = Vec::<u8>::with_capacity(1024);
    // ... use data ...
}   // ← data is dropped here: 1024 bytes freed, instantly, deterministically

How the Compiler Enforces It

The borrow checker is the component of the Rust compiler (rustc) that enforces the ownership rules. It performs a static analysis of your code at compile time, tracking the ownership and lifetime of every value through every possible code path.

When the borrow checker rejects your code, it is not being pedantic. It has found a path — possibly one you didn't think of — where a value would be used after it was freed, or where two parts of your program would hold mutable access to the same data simultaneously. The error messages are the compiler showing you the bug.

Ownership vs. Garbage Collection

The tradeoff is straightforward. Garbage-collected languages give you convenience: you don't think about when memory is freed. Ownership gives you predictability: you always know when resources are cleaned up, and you pay zero runtime cost for that knowledge.

In practice, ownership also gives you something subtler: documentation. A function signature that takes String (by value) tells you it will consume the string. A signature that takes &str tells you it's just borrowing. The ownership model encodes intent into the type system in a way that garbage-collected languages simply cannot.

Common Patterns

Idiomatic Rust code works with ownership rather than around it. The most common patterns are:

• Borrowing — lending access to a value without transferring ownership, via &T (shared) or &mut T (exclusive).
• Cloning — explicitly duplicating a value when you genuinely need two independent copies. The .clone() call makes the cost visible.
• Returning ownership — a function that needs to create a value and give it to the caller simply returns it; ownership moves to the caller automatically.
• Using Copy types — simple stack values (integers, booleans, char) implement Copy and are duplicated implicitly on assignment, because copying them is trivially cheap.

Related Concepts