Borrowing rules

What it is and why it exists

Borrowing accesses a value through a reference without taking over its ownership. A reference is not responsible for freeing the referenced value; the value is still destroyed under the ownership rules when its owner leaves scope. Borrowing therefore fits an interface that temporarily uses data and then returns control.

Rust distinguishes a shared reference &T from a mutable reference &mut T. Shared references let readers coexist but cannot write ordinary data through the reference. A mutable reference allows reading and writing, but requires exclusive access to the corresponding memory region.

These constraints address reference validity and writes through aliases. If code retains an element pointer after a collection reallocates, the pointer could dangle; if one alias writes while a reader observes the same data, the read could lose a consistent meaning. The borrow checker rejects those overlaps at compile time, so safe Rust does not defer the check to a runtime path that might happen to execute.

You meet borrowing in function parameters, slices, iterators, pattern matching, and method calls. An interface accepting &str or &[T] usually observes caller-owned data; one accepting &mut T can change that same value during the call; one accepting T can consume or transfer ownership.

How it works

For one value or overlapping memory regions, the rules reduce to two constraints: every reference that will be used again must remain valid, and an access can have one or more shared references or one mutable reference, without conflicting uses of both. “Shared” and “exclusive” describe access permissions, not whether a binding was declared with mut.

let view = &value creates a shared borrow. You can copy the shared reference or take a shorter shared borrow through it. A shared reference cannot directly write an ordinary T, but interior-mutability tools such as Cell, RefCell, locks, and atomic types have their own checking rules. “The underlying data can never change while &T exists” is therefore not a universal description.

let edit = &mut value creates a mutable borrow when the binding permits mutation and no conflicting access covers the region. Because &mut T represents exclusive permission, it does not implement Copy like &T does. Assigning it directly to another variable can move the reference; when an operation only needs the permission briefly, you can create an explicit reborrow.

The borrow checker analyzes place expressions and the regions that may overlap. It can directly see that distinct fields of a struct do not overlap, but it generally does not prove that two slice indices differ. Library APIs such as split_at_mut establish a safe boundary internally and return two independent mutable slices for disjoint regions.

A borrow’s duration follows later uses of its reference and the control flow, rather than necessarily lasting to the enclosing closing brace. This model is called non-lexical lifetimes (NLL) . After a reference’s last use, if no path reads it again, later code can usually begin a borrow that would otherwise conflict.

The following access table connects interface intent to what the caller may do. It covers ordinary safe references; the boundary section treats interior mutability and synchronization separately.

Read “borrowed as immutable,” “borrowed as mutable,” and “borrow later used here” together in compiler errors. Find the first borrow, its last use, and the intervening access that needs the opposite permission. The diagnostic marks a conflict interval; it does not say that the variable can never be used again.

Examples

Multiple shared readers

The first example lets checkout and audit logic inspect the same price vector. Both references only read, so they can coexist. order_total accepts a slice, allowing it to handle a Vec<u32>, an array, or another slice.

checkout and audit both borrow prices; neither takes ownership of the vector or its buffer. The owner prices remains alive until the end of main, so both references remain valid.

Using &[u32] instead of &Vec<u32> limits the interface to the capability it needs: reading a contiguous sequence. Borrowing rules do more than prevent errors; they help an API state its permissions.

Shared reading followed by exclusive mutation

The second example prints a shared snapshot before changing the balance. The last use of snapshot occurs before the call to debit, so NLL permits the later mutable borrow without an extra block.

fn debit(balance: &mut u32, amount: u32) {
    *balance = balance.saturating_sub(amount);
}

fn main() {
    let mut balance = 5_000;

    let snapshot = &balance;
    println!("before: {snapshot}");

    debit(&mut balance, 750);
    println!("after debit: {balance}");

    let correction = &mut balance;
    *correction += 200;
    println!("through mutable borrow: {correction}");

    println!("final: {balance}");
}

before: 5000
after debit: 4250
through mutable borrow: 4450
final: 4450

The signature of debit says that it may change the balance but does not retain ownership. Once the call returns, the mutable borrow ends, and main still owns and can read balance.

correction is last used by the third output line. Reading balance afterward does not conflict with it. If correction were used again after the final output, the two access ranges would overlap and the compiler would reject the direct read of balance.

Mutating two elements after splitting

Taking mutable references to both stock[from] and stock[to] is conservatively treated as a possible overlap because the indices might be equal. split_at_mut(2) divides the slice into two regions proven not to overlap, after which the program can borrow one element from each side.

fn move_one(source: &mut u32, destination: &mut u32) -> bool {
    if *source == 0 {
        return false;
    }

    *source -= 1;
    *destination += 1;
    true
}

fn main() {
    let mut stock = [4, 1, 0, 3];

    let (west, east) = stock.split_at_mut(2);
    let moved = move_one(&mut west[1], &mut east[0]);

    println!("moved: {moved}");
    println!("stock: {stock:?}");
}

moved: true
stock: [4, 0, 1, 3]

west covers the first two elements of the original array and east covers the last two. The safe API still returns ordinary &mut [u32] values, so the caller needs neither raw pointers nor unsafe.

The left and right slices are not used after the call to move_one, so the program can finally read all of stock. If later code used west or east, the whole-array borrow would remain active and the direct read would conflict.

Returning a view into an input

A function can return a reference, but the result must come from an input that lives long enough. Lifetime elision connects the output of first_word to its only reference input. It neither copies the word nor gives label a longer lifetime.

fn first_word(text: &str) -> &str {
    text.split_once(' ')
        .map_or(text, |(first, _)| first)
}

fn main() {
    let mut label = String::from("priority order");

    let word = first_word(&label);
    println!("first: {word}");

    label.push_str(" ready");
    println!("label: {label}");
}

first: priority
label: priority order ready

word points into the buffer owned by label, so push_str cannot potentially change that buffer before word is printed. Once the print is its last use, NLL permits the mutation.

If the function tried to return a slice of a String created inside the function, the owner would be destroyed on return and the result would dangle. The correct interface returns an owned String, or takes the reference from caller-provided input as this one does.

Pitfalls

Fix: Extract the small owned value you really need before mutating, or retain an index and borrow again afterward. If the domain needs stable addresses, choose a data structure that provides that guarantee instead of inferring safety from a run that happened not to reallocate.

Fix: State the interface intent first. Prefer &str for read-only text and &[T] for read-only sequences. Clone only when the result genuinely needs independent ownership, and call out that ownership decision in review.

Fix: Return an owned value, or make the result clearly borrow from an input. Treat lifetimes as relationship constraints between references, not instructions that extend an allocation.

Fix: Create a shorter reborrow such as let short = &mut *original when you only need to lend the permission temporarily. Make the last use of short occur early, then continue through original.

Fix: Trace the first borrow, conflicting access, and later use marked by the diagnostic. Reorder reads and writes when possible, split data when two regions are needed, and select interior mutability or synchronization only when shared long-lived mutation is part of the design.

Further reading

• The Rust Programming Language: References and borrowing
• The Rust Reference: Borrow operators
• Rust standard library: slice::split_at_mut
• RFC 2094: Non-lexical lifetimes