6.4 Rust’s Borrowing Rules in Detail

Rust’s safety rests on enforcing that an object may be accessed either by:

  • Any number of immutable references (&T), or
  • Exactly one mutable reference (&mut T).

Although these restrictions might feel overbearing, especially in single-threaded code, they prevent data corruption and undefined behavior. They also allow the compiler to make more aggressive optimizations, knowing it will not encounter overlapping writes (outside of unsafe or interior mutability).

6.4.1 Benefits of Rust’s Borrowing Rules

  1. Prevents Data Races: Only one writer at a time.
  2. Maintains Consistency: Immutable references do not experience unexpected changes in data.
  3. Eliminates Undefined Behavior: Disallows unsafe aliasing of mutable data.
  4. Optimizations: The compiler can safely optimize, assuming no overlaps occur among mutable references.
  5. Clear Reasoning: You can instantly identify where and when data may be changed.

6.4.2 Problems Without These Rules

Even single-threaded code with overlapping mutable references can end up with:

  • Data Corruption: Multiple references writing to the same data.
  • Hard-to-Debug Bugs: Unintended side effects from multiple pointers.
  • Invalid Reads: One pointer may free or reallocate memory while another pointer still references it.

6.4.3 Example in C Without Borrowing Rules

#include <stdio.h>

void modify(int *a, int *b) {
    *a = 42;
    *b = 99;
}

int main() {
    int x = 10;
    modify(&x, &x); // Passing the same pointer twice
    printf("x = %d\n", x);
    return 0;
}

Depending on compiler optimizations, the result can be inconsistent. Rust forbids this ambiguous usage at compile time.

6.4.4 Rust’s Approach

By applying these borrowing rules during compilation, Rust avoids confusion and memory pitfalls. In advanced cases, interior mutability (via types like RefCell<T>) allows more flexibility with runtime checks. Even then, Rust makes sure you cannot inadvertently violate fundamental safety guarantees.