Understanding Rust Borrowing: Multiple Immutable vs Single Mutable References

Overview

Rust enforces memory safety through a strict borrowing system. The rules govern how immutable ( &T) and mutable ( &mut T) references may coexist within a single lifetime, preventing data races and undefined behavior.

Borrowing Rules

Any number of immutable references may exist simultaneously.

Only one mutable reference may exist at a time.

Immutable and mutable references cannot coexist in the same lifetime.

The phrase “at the same time” refers to the *lifetime* of a reference—the region of code during which the reference is valid.

Detailed Explanation

3.1 Multiple Immutable References

Within a single lifetime you can create as many immutable references as needed. All such references are read‑only and may be used together.

let a = 1;          // immutable value
let r1 = &a;        // first immutable reference
let r2 = &a;        // second immutable reference
println!("{} {}", r1, r2); // both can be used concurrently

3.2 Single Mutable Reference

A mutable reference grants exclusive access to the underlying data. While a mutable reference is active, no other references—mutable or immutable—may point to the same value.

Mutable reference active → no other references to that variable.

Immutable reference active → no mutable reference to that variable.

Example 1 – mutable reference conflicts with an immutable reference:

let mut a = 1;
let r1 = &mut a; // mutable reference
let r2 = &a;      // error: cannot borrow `a` as immutable while it is borrowed as mutable
println!("{}", r1);

Example 2 – immutable reference conflicts with a mutable reference:

let mut a = 1;
let r1 = &a;      // immutable reference
let r2 = &mut a;   // error: cannot borrow `a` as mutable because it is also borrowed as immutable
println!("{}", r1);

3.3 Immutability vs. Mutability Exclusivity

The third rule restates that immutable and mutable references cannot overlap in the same lifetime. This guarantees that a piece of data is never simultaneously read‑only and writable.

Note: Reborrowing and Its Effect

When you dereference a mutable reference ( *) and then take a reference to the result, the new reference is immutable. This “reborrow” can unintentionally violate the exclusivity rule because the original mutable reference and the new immutable reference now share the same lifetime.

let mut a = 1;
let r1 = &mut a;   // mutable reference
let r2 = &*r1;      // reborrow → immutable reference
println!("{} {}", r1, r2); // compile error: cannot have mutable and immutable references simultaneously

Conclusion

Understanding and applying these borrowing rules enables Rust developers to write safe, race‑free concurrent code. By structuring code around lifetimes and respecting the exclusivity of mutable access, memory errors are eliminated at compile time.