Ownership

What it is and why it exists

Ownership is Rust’s set of language rules for stating who is responsible for a value, when that responsibility transfers, and when the value ends. A value may own more than heap memory: it may own a file, socket, lock guard, or another resource that needs cleanup. The compiler checks the rules at compile time, while a type’s destruction logic runs as the corresponding scope exits at runtime.

Each value has a current owner, and two variables cannot independently own the same ordinary owned value at once. Assignment, by-value arguments, and by-value returns can transfer responsibility from one place to another; this is move semantics . Rejecting the old binding after a move leaves one owning path responsible for releasing the resource.

When an owner leaves scope, Rust runs the value’s destruction logic and then releases the resources it owns. This pattern is Resource Acquisition Is Initialization (RAII) : a resource’s lifetime is tied to its owning value instead of waiting for a garbage collector to find an unreachable object. Control flow and scope usually determine the release point directly.

Not every assignment invalidates the source. Types that implement Copy are copied implicitly on assignment and by-value calls; examples include integers, booleans, and many structs whose fields are all Copy. A String owns a heap buffer and does not implement Copy, so assignment moves it by default; call clone() explicitly when you need another copy of the string data.

Borrowing lets a function access a value temporarily without taking ownership. &T is a shared borrow and &mut T is an exclusive mutable borrow. Ownership answers “who is ultimately responsible for ending this value,” while borrowing answers “who may access this value for some period.”

You encounter ownership in function signatures, collection iteration, pattern matching, closure capture, and thread boundaries. It is a resource-responsibility model, not a performance rule that says “never copy.” Express responsibility accurately first, then use analysis and measurement to decide whether copies or allocations should be reduced.

How it works

Separate bindings, values, and resources when reasoning about ownership. A variable name binds to a value, and that value may own a resource elsewhere; for example, a String value manages a growable UTF-8 buffer. Moving a String transfers responsibility for managing the buffer without creating a second copy of its text.

Rust teaching material commonly summarizes the basic rules as follows:

1. Each value has an owner.
2. There can be only one owner at a time.
3. The value is dropped when its owner leaves scope.

These rules describe single ownership by default. Types such as Rc<T> and Arc<T> model several owning handles through their own APIs, but the responsibility remains explicit: the last strong owner ends the value. The details of counts and thread behavior belong to the smart-pointer topic.

A move is a static state change

After let next = current; for a non-Copy value, next is the owner. The compiler treats current as moved instead of waiting for a runtime check before each use. An old variable can be assigned and used again when every control-flow path proves that it has received a new value.

A by-value argument also moves a value because the callee’s parameter is a new owning place. A by-value return moves the returned value to the caller. The compiler eliminates many physical shuffles used only to express these semantics, so a language-level move does not mean “copy the entire heap object.”

A move can affect only one field of a struct. Unmoved fields may still be used separately afterward, but the whole struct normally cannot be used as a complete value. Types that implement Drop are more restricted because their destructor must receive a complete, valid self.

Copy and Clone are different contracts

Copy is a marker trait with no methods. Once a type implements it, ordinary assignment leaves the source binding available, and that copy cannot run custom code. A type that implements Drop cannot also implement Copy, because implicit duplication would make destruction responsibility ambiguous.

Clone provides an explicit clone() method and lets a type define how it creates a logical copy. Cloning a String copies its text data; cloning an Rc<T> only increments the shared-owner count; cloning a custom type follows its implementation. For every .clone(), inspect the receiver type to determine cost and ownership meaning.

Copy is not a synonym for “stored on the stack.” Shared references and some values containing pointers can be Copy, while a fixed-size stack value may own resources or implement Drop and therefore cannot be Copy. The type contract decides, not a guessed storage location.

Borrowing preserves the ownership boundary

A function that only reads a value during its call usually accepts &T. One that mutates without retaining the value usually accepts &mut T. Taking T by value accurately signals a responsibility change when the function must store, transfer, or eventually destroy the value.

A borrow has its own valid region. A reference cannot outlive the owner, and conflicting shared and mutable access cannot overlap. The compiler normally ends a borrow after the reference’s last use instead of mechanically extending it to a closing brace. The related topics cover conflict rules and lifetime annotations in detail.

Drop completes the handoff

Rust automatically calls Drop::drop as a scope exits; callers cannot invoke that method directly. To end a value early, the standard drop(value) function takes it by value and lets destruction finish before the function returns. Calling drop(&value) only ends that copyable reference, not the referenced value.

Local variables are generally dropped in reverse declaration order, while struct fields are dropped in declaration order. Early return and an unwinding panic also drop initialized local values that remain alive. Paths such as std::process::exit, process abort, and strong reference-counting cycles can bypass expected destruction, so ownership guarantees memory safety rather than guaranteeing that every destructor runs.

Examples

The following four programs demonstrate by-value transfer, Copy and Clone, borrowing, and deterministic destruction. Each was executed locally with Rust 1.98.0 using cargo run, and the output blocks contain the real results.

Moving ownership into and out of a function

approve takes a Ticket by value, so ownership moves from main into the call. Its return transfers ownership back to the caller; binding the result under the same name makes the state transition read as one continuous flow.

The first ticket has been moved after the call, and the second binding with the same name owns the returned value. This shadowing does not restore the old value; it gives a suitable domain name to the new owner. If approve did not need to retain or return the ticket, accepting &mut Ticket would let the caller keep ownership throughout.

Comparing an implicit copy with an explicit clone

The integer implements Copy, so retry_limit remains usable after assignment. Shipment contains a String and cannot implement Copy; its derived Clone implementation explicitly creates an independent shipment record.

#[derive(Clone, Debug)]
struct Shipment {
    route: String,
    priority: u8,
}

fn main() {
    let retry_limit = 3;
    let copied_limit = retry_limit;

    let original = Shipment {
        route: String::from("Paris-Lyon"),
        priority: 1,
    };
    let mut rerouted = original.clone();
    rerouted.route = String::from("Paris-Dijon");
    rerouted.priority = 2;

    println!("limits: {retry_limit}, {copied_limit}");
    println!("original: {original:?}");
    println!("rerouted: {rerouted:?}");
}

limits: 3, 3
original: Shipment { route: "Paris-Lyon", priority: 1 }
rerouted: Shipment { route: "Paris-Dijon", priority: 2 }

Changing the clone does not change the original because the two String values own separate buffers. That result follows from the derived Clone implementation cloning each Shipment field; it does not mean every .clone() performs a deep copy. A shared pointer usually creates another owning handle when cloned.

Borrowing instead of transferring

note_count only reads an order, so it accepts &Order; add_note must mutate it, so it accepts &mut Order. Neither function retains the order, and ownership stays in main throughout.

#[derive(Debug)]
struct Order {
    number: String,
    notes: Vec<String>,
}

fn note_count(order: &Order) -> usize {
    order.notes.len()
}

fn add_note(order: &mut Order, note: &str) {
    order.notes.push(note.to_owned());
}

fn main() {
    let mut order = Order {
        number: String::from("A-17"),
        notes: vec![String::from("paid")],
    };

    println!("{} has {} note", order.number, note_count(&order));
    add_note(&mut order, "packed");
    println!("{} has {} notes", order.number, note_count(&order));
}

A-17 has 1 note
A-17 has 2 notes

The first shared borrow is no longer used after its println!, so the later mutable borrow is valid. note is a borrowed &str, but the order must retain the text after the function returns, so to_owned() creates a String at the real retention boundary. That allocation belongs to the interface semantics; it is not there merely to appease the compiler.

Observing scopes and explicit drop

The Traced destructor prints a name, making drop order visible. The inner _buffer is dropped automatically when its block ends, while connection ends early through drop.

struct Traced(&'static str);

impl Drop for Traced {
    fn drop(&mut self) {
        println!("drop {}", self.0);
    }
}

fn main() {
    let connection = Traced("connection");
    {
        let _buffer = Traced("buffer");
        println!("inside scope");
    }

    println!("after inner scope");
    drop(connection);
    println!("after explicit drop");
}

inside scope
drop buffer
after inner scope
drop connection
after explicit drop

drop(connection) consumes the value, so connection cannot be used afterward. Destructors on real types normally release resources without printing; the output only exposes the timing. To release a lock guard, drop the guard itself rather than a reference to it.

Pitfalls

Using an old binding after a move

Fix: Check whether the callee must retain or destroy the value. Use &T for reading, &mut T for in-place mutation, stop using the old binding after a real transfer, or return ownership from the function. Clone only when the contract requires two independent values.

Cloning away every ownership error

Fix: For each clone, state who owns the new copy and why it must be independent. Try shortening a borrow, moving the value, or changing the parameter type first. Justify a retained clone using the type’s semantics and measurement when needed, not a blanket claim that cloning is cheap.

Guessing Copy from storage location

Fix: Check whether the type implements Copy and whether all its fields permit that implementation. Derive Copy for a custom type only when implicit duplication matches the domain semantics. Use Clone or keep move semantics when copying needs explicit confirmation, allocation, or count updates.

Missing a partial move

Fix: Use ref in a pattern or match a reference when you only need to read. When a field must be extracted, destructure the complete value or model the field as Option<T> and call take() to leave a valid state. Do not use unsafe code to bypass destructor invariants.

Treating destruction as inevitable

Fix: Give files, locks, and transactions the smallest practical lexical scope, and do not put a required durable commit only in Drop. Mark owning edges in reference graphs and use Weak for non-owning back edges. Commit or flush explicitly during normal shutdown, leaving destruction as protection for exceptional paths.

Further reading

• The Rust Programming Language: What Is Ownership?
• The Rust Programming Language: References and Borrowing
• The Rust Reference: Destructors
• Rust standard library: Clone
• Rust standard library: Copy