Why borrowing is required in Rust - Why It Works This Way

Overview - Why borrowing is required

What is it?

Borrowing in Rust is a way to let one part of your program use data owned by another part without taking ownership. It allows multiple parts to read or one part to modify data safely without copying it. Borrowing helps manage memory and data access rules at compile time to prevent bugs. It is a core feature that makes Rust programs safe and efficient.

Why it matters

Without borrowing, programs would need to copy data everywhere or risk unsafe access, leading to bugs like crashes or corrupted data. Borrowing solves the problem of sharing data safely without wasting memory or causing conflicts. It lets Rust guarantee memory safety without a garbage collector, making programs fast and reliable. This means fewer runtime errors and better performance in real-world software.

Where it fits

Before learning borrowing, you should understand ownership, which is how Rust tracks who controls data. After mastering borrowing, you can learn about lifetimes, which tell Rust how long borrowed data is valid. Borrowing is a bridge between owning data and safely sharing it in Rust programs.

Mental Model

Core Idea

Borrowing lets you use data temporarily without taking ownership, ensuring safe and controlled access.

Think of it like...

Borrowing is like lending a book to a friend: you keep ownership of the book, but your friend can read it for a while without taking it away permanently.

Owner ──► Data
  │
  ├─ Borrower (read-only) ──► Data (shared access)
  └─ Borrower (mutable) ──► Data (exclusive access)

Build-Up - 7 Steps

1

Foundation

Understanding Ownership Basics

Concept: Ownership means one variable controls a piece of data and is responsible for cleaning it up.

In Rust, every value has a single owner. When the owner goes out of scope, Rust automatically frees the data. For example: let s = String::from("hello"); // s owns the string data When s goes out of scope, the string memory is freed.

Result

The program manages memory automatically without leaks or manual cleanup.

Understanding ownership is key because borrowing depends on knowing who owns the data at any time.

2

Foundation

Why Ownership Alone Limits Sharing

Concept: Ownership rules prevent multiple owners to avoid conflicts, but this limits sharing data easily.

If you try to assign ownership to another variable, the original owner loses it: let s1 = String::from("hello"); let s2 = s1; // s1 loses ownership // s1 can no longer be used This means you cannot have two owners at once, which makes sharing data tricky.

Result

Rust prevents data races and double frees but restricts easy data sharing.

Knowing this limitation shows why borrowing is needed to safely share data without transferring ownership.

3

Intermediate

Introducing Borrowing for Shared Access

Concept: Borrowing lets you create references to data without taking ownership, allowing safe sharing.

You can create a reference to data using &: let s = String::from("hello"); let r = &s; // r borrows s You can use r to read s without owning it. Multiple references can exist at once if they only read.

Result

You can safely read data from multiple places without copying or ownership transfer.

Borrowing enables flexible data access while preserving ownership rules and safety.

4

Intermediate

Mutable Borrowing for Controlled Changes

Concept: You can borrow data mutably to change it, but only one mutable borrow is allowed at a time.

Using &mut lets you borrow data to modify it: let mut s = String::from("hello"); let r = &mut s; // mutable borrow r.push_str(", world"); Rust enforces only one mutable borrow or any number of immutable borrows at once.

Result

Data can be safely modified without conflicts or data races.

This rule prevents bugs from simultaneous conflicting changes, ensuring safe mutation.

5

Intermediate

Borrowing Prevents Dangling References

🤔Before reading on: do you think Rust allows references to data that no longer exists? Commit to yes or no.

Concept: Rust uses borrowing rules and lifetimes to ensure references never outlive the data they point to.

If you try to return a reference to a local variable, Rust will give an error: fn get_ref() -> &String { let s = String::from("hello"); &s // error: s will be dropped } This prevents dangling references that cause crashes.

Result

Rust guarantees memory safety by preventing invalid references at compile time.

Understanding this shows how borrowing is essential for safe memory without runtime checks.

6

Advanced

Borrowing Enables Zero-Cost Abstractions

🤔Before reading on: do you think borrowing adds runtime overhead like copying data? Commit to yes or no.

Concept: Borrowing lets Rust programs share data without copying, so there is no runtime cost for safety.

References are pointers under the hood, so borrowing just passes addresses. This means you can write safe, high-level code without slowing down your program. For example, functions can take &String instead of String to avoid copying: fn print_str(s: &String) { println!("{}", s); } This is efficient and safe.

Result

Borrowing combines safety with performance, a key Rust advantage.

Knowing this explains why borrowing is central to Rust's design for fast, safe systems programming.

7

Expert

Borrowing and Lifetimes: The Safety Guarantee

🤔Before reading on: do you think Rust can always infer how long a borrow lasts without extra hints? Commit to yes or no.

Concept: Borrowing works with lifetimes, which tell Rust how long references are valid to prevent use-after-free errors.

Lifetimes are annotations that describe the scope of borrows. Sometimes Rust infers them, but complex cases need explicit lifetimes: fn longest<'a>(x: &'a str, y: &'a str) -> &'a str { if x.len() > y.len() { x } else { y } } This ensures the returned reference is valid as long as both inputs.

Result

Lifetimes make borrowing safe even in complex scenarios involving multiple references.

Understanding lifetimes is crucial to mastering borrowing and writing correct, safe Rust code.

Under the Hood

At runtime, borrowing uses pointers to refer to data without copying it. The Rust compiler enforces borrowing rules at compile time using a borrow checker. This checker tracks ownership and references, ensuring no data races, no dangling pointers, and exclusive mutable access. Lifetimes are metadata that help the compiler verify references do not outlive their data. This static analysis prevents many bugs before the program runs.

Why designed this way?

Rust was designed to provide memory safety without a garbage collector. Borrowing and lifetimes allow safe sharing and mutation of data with zero runtime cost. Alternatives like reference counting or garbage collection add overhead or complexity. The borrow checker enforces strict rules early to avoid runtime errors, making Rust suitable for systems programming where performance and safety are critical.

┌─────────────┐       ┌─────────────┐
│   Owner     │──────▶│   Data      │
└─────────────┘       └─────────────┘
       │
       │ borrows
       ▼
┌─────────────┐
│ Borrower(s) │
│  (read-only)│
└─────────────┘

Only one mutable borrower allowed:

┌─────────────┐
│ Borrower    │
│ (mutable)   │
└─────────────┘

Compiler checks lifetimes and exclusivity.

Myth Busters - 4 Common Misconceptions

Quick: Do you think you can have multiple mutable borrows of the same data at once? Commit to yes or no.

Common Belief: You can have many mutable references to the same data simultaneously as long as you are careful.

Reality: Rust only allows one mutable borrow at a time to prevent data races and undefined behavior.

Why it matters: Allowing multiple mutable borrows can cause unpredictable bugs and crashes due to conflicting changes.

Quick: Do you think borrowing causes runtime overhead like copying data? Commit to yes or no.

Common Belief: Borrowing slows down programs because it copies data or adds checks at runtime.

Reality: Borrowing uses references (pointers) and is checked at compile time, so it adds no runtime overhead.

Why it matters: Misunderstanding this might lead programmers to avoid borrowing and write inefficient code.

Quick: Do you think Rust allows references to data that has already been dropped? Commit to yes or no.

Common Belief: Rust lets you create references to any data, even if it might be invalid later.

Reality: Rust's borrow checker and lifetimes prevent references to data that no longer exists, avoiding dangling pointers.

Why it matters: Allowing dangling references causes crashes and security vulnerabilities.

Quick: Do you think borrowing is only about syntax and not about safety? Commit to yes or no.

Common Belief: Borrowing is just a way to write shorter code without copying, not related to safety.

Reality: Borrowing enforces strict safety rules that prevent common bugs like data races and invalid memory access.

Why it matters: Ignoring borrowing's safety role can lead to unsafe code and hard-to-find bugs.

Expert Zone

1

Mutable borrowing enforces exclusive access at compile time, preventing subtle concurrency bugs without runtime locks.

2

Borrowing combined with lifetimes allows Rust to express complex data relationships safely, which many other languages cannot do statically.

3

The borrow checker's rules sometimes feel restrictive but are designed to guarantee safety; understanding its logic helps write idiomatic Rust.

When NOT to use

Borrowing is not suitable when you need shared mutable state across threads; in such cases, synchronization primitives like Mutex or Atomic types should be used. Also, when ownership transfer is needed, passing ownership instead of borrowing is better. For long-lived shared data, reference counting (Rc or Arc) is an alternative.

Production Patterns

In real-world Rust code, borrowing is used extensively to pass data to functions without copying, enabling zero-cost abstractions. Libraries use borrowing to provide safe APIs that prevent misuse. Complex lifetime annotations appear in asynchronous code and data structures like graphs to ensure safety. Borrowing also underpins Rust's concurrency model by preventing data races at compile time.

Connections

Reference Counting (Rc/Arc)

Alternative memory management technique for shared ownership

Understanding borrowing clarifies when to use Rc or Arc for shared ownership with runtime checks versus borrowing's compile-time guarantees.

Garbage Collection

Different approach to memory safety and management

Comparing borrowing with garbage collection highlights Rust's unique zero-cost safety model without runtime pauses.

Linguistics: Pronouns and Ownership

Metaphor for ownership and borrowing in language

Just as pronouns refer to nouns without owning them, borrowing refers to data without ownership, showing how language concepts can mirror programming ideas.

Common Pitfalls

#1 Trying to use a reference after the original data is dropped.

Wrong approach:

fn get_ref() -> &String {
let s = String::from("hello");
&s
}

let r = get_ref();
println!("{}", r);

Correct approach:

fn get_ref() -> String {
let s = String::from("hello");
s
}

let r = get_ref();
println!("{}", r);

Root cause:

Misunderstanding that references must not outlive the data they point to.

#2 Having multiple mutable references to the same data at once.

Wrong approach:

let mut s = String::from("hello");
let r1 = &mut s;
let r2 = &mut s;
r1.push_str(" world");
r2.push_str("!");

Correct approach:

let mut s = String::from("hello");
let r1 = &mut s;
r1.push_str(" world");
// r1 goes out of scope here
let r2 = &mut s;
r2.push_str("!");

Root cause:

Not knowing Rust enforces only one mutable borrow at a time to prevent conflicts.

#3 Trying to modify data through an immutable reference.

Wrong approach:

let s = String::from("hello");
let r = &s;
r.push_str(" world");

Correct approach:

let mut s = String::from("hello");
let r = &mut s;
r.push_str(" world");

Root cause:

Confusing immutable and mutable references and their permissions.

Key Takeaways

Borrowing lets you use data without taking ownership, enabling safe and efficient sharing.

Rust enforces borrowing rules at compile time to prevent bugs like data races and dangling pointers.

Only one mutable borrow or many immutable borrows are allowed at a time to ensure safety.

Borrowing has zero runtime cost because it uses references checked by the compiler.

Understanding borrowing is essential to mastering Rust's memory safety and performance model.

Practice

1. Why does Rust require borrowing when accessing data instead of always transferring ownership?

easy

A. To allow multiple parts of code to read data without copying it

B. To make the code run slower for safety

C. To force programmers to write more code

D. To prevent any data from being changed

Solution

1. Step 1: Understand ownership and borrowing

   Ownership means one variable controls the data. Borrowing lets others use data without owning it.

2. Step 2: Why borrowing is useful

   Borrowing allows multiple parts of code to read data safely without making copies or moving ownership.

3. Final Answer:

   To allow multiple parts of code to read data without copying it -> Option A

4. Quick Check:

   Borrowing = safe shared access [OK]

Hint: Borrowing means sharing data without moving ownership [OK]

Common Mistakes:

• Thinking borrowing slows down code
• Believing borrowing prevents all data changes
• Confusing borrowing with copying data

2. Which of the following is the correct syntax to borrow a variable immutably in Rust?

easy

A. let x = ref value;

B. let x = &value;

C. let &x = value;

D. let mut x = &mut value;

Solution

1. Step 1: Identify borrowing syntax

   In Rust, borrowing immutably uses the ampersand before the variable: &value.

2. Step 2: Match correct syntax

   The correct way to bind a reference is let x = &value;. Other options are invalid or mean something else.

3. Final Answer:

   let x = &value; -> Option B

4. Quick Check:

   Immutable borrow = &value [OK]

Hint: Use & before variable to borrow immutably [OK]

Common Mistakes:

• Using let x = ref value; invalid syntax
• Confusing &x with &value
• Using mutable borrow (&mut) for immutable access

3. What will be the output of this Rust code?

fn main() {
    let s = String::from("hello");
    let r1 = &s;
    let r2 = &s;
    println!("{} and {}", r1, r2);
}

medium

A. hello and hello

B. Compilation error due to multiple mutable borrows

C. hello and error

D. Runtime error

Solution

1. Step 1: Analyze borrowing in code

   Two immutable references r1 and r2 borrow s simultaneously, which is allowed.

2. Step 2: Check output of println!

   Both references print the string "hello", so output is "hello and hello".

3. Final Answer:

   hello and hello -> Option A

4. Quick Check:

   Multiple immutable borrows print values [OK]

Hint: Multiple immutable borrows allowed, prints values [OK]

Common Mistakes:

• Thinking multiple immutable borrows cause errors
• Confusing mutable and immutable borrow rules
• Expecting runtime errors for borrowing

4. Identify the error in this Rust code and why borrowing is required:

fn main() {
    let mut s = String::from("hello");
    let r1 = &s;
    let r2 = &mut s;
    println!("{} and {}", r1, r2);
}

medium

A. No error, code runs fine

B. Cannot borrow `s` as immutable because it is mutable

C. Cannot borrow `s` as mutable because it is already borrowed as immutable

D. Cannot print two variables in println!

Solution

1. Step 1: Check borrowing rules

   Rust forbids mutable borrow while immutable borrow exists to prevent data races.

2. Step 2: Identify error cause

   Here, r1 immutably borrows s, then r2 tries mutable borrow, causing compile error.

3. Final Answer:

   Cannot borrow `s` as mutable because it is already borrowed as immutable -> Option C

4. Quick Check:

   Mutable borrow blocked by existing immutable borrow [OK]

Hint: Mutable borrow blocked if immutable borrow exists [OK]

Common Mistakes:

• Thinking mutable borrow is allowed with immutable borrow
• Ignoring borrow checker errors
• Assuming println! causes error

5. You want to write a function that changes a string passed to it without taking ownership. Which borrowing type should you use and why?

hard

A. Immutable borrow (&) because it allows reading the string safely

B. Copy the string inside the function to modify it

C. Ownership transfer because borrowing is not needed for modification

D. Mutable borrow (&mut) because it allows modifying the string without ownership

Solution

1. Step 1: Understand function parameter needs

   To modify data inside a function without taking ownership, you must borrow it mutably.

2. Step 2: Choose correct borrow type

   Mutable borrow &mut allows changing the original data safely without moving ownership.

3. Final Answer:

   Mutable borrow (&mut) because it allows modifying the string without ownership -> Option D

4. Quick Check:

   Modify data = use &mut borrow [OK]

Hint: Use &mut to change data without ownership transfer [OK]

Common Mistakes:

• Using immutable borrow when modification is needed
• Transferring ownership unnecessarily
• Copying data instead of borrowing