Common Borrow Checker Errors and Their Solutions
You're writing a function to update a user's profile. You grab a reference to the name to validate it, then try to update the email. The compiler screams. You stare at the code. It looks fine. The compiler says you're borrowing something twice. You feel like the compiler is gaslighting you. It isn't. The compiler is protecting you from a data race that would crash your program at 3 AM.
Borrow checker errors happen when you break Rust's rules about references. The rules are simple, but they enforce a discipline that prevents entire classes of bugs. Once you internalize the pattern, the errors stop feeling like obstacles and start feeling like a safety net.
The whiteboard rule
Think of a whiteboard in a meeting room. Multiple people can look at the whiteboard at the same time. That's immutable borrowing. Everyone reads, no one changes. If someone wants to erase and rewrite, they need exclusive access. You can't have one person erasing while another is reading the old text. The text would be half-erased, half-new. The reader gets garbage.
Rust enforces this rule at compile time. You can have many immutable references, or exactly one mutable reference. Never both at the same time.
A borrow is a reference. It's a way to look at data without taking ownership. Mutable means you can change it. Immutable means you can only read it. A lifetime is how long a reference stays valid. If the data disappears, the reference becomes a dangling pointer. Rust checks that references never outlive the data they point to.
Trust the rules. They exist because memory safety is hard.
Minimal example
This code compiles because the borrows don't overlap.
fn main() {
let mut s = String::from("hello");
// Immutable borrow: we're just reading.
let r1 = &s;
// Another immutable borrow is fine.
// Multiple readers don't conflict.
let r2 = &s;
println!("{} and {}", r1, r2);
// r1 and r2 are done. The compiler sees this.
// Now we can get a mutable borrow.
let r3 = &mut s;
r3.push_str(" world");
println!("{r3}");
}
The compiler tracks the last use, not just the scope. Write code that flows, and the borrows will follow.
How the compiler tracks borrows
Rust uses Non-Lexical Lifetimes. The compiler doesn't just look at braces to decide when a borrow ends. It looks at the last time the variable is used. In the example above, r1 and r2 are used in the println!. After that line, the compiler marks them as dead. r3 starts after r1 and r2 are dead. So the mutable borrow is safe.
This means you rarely need to manually end borrows with extra blocks. The compiler is smart about the last use. If you have a borrow that seems to live too long, check if you're using the variable later than you think. Sometimes a stray println! or a debug log keeps a borrow alive longer than intended.
Convention aside: Rust 2018 introduced Non-Lexical Lifetimes. If you're reading old tutorials that show workarounds with { } blocks to drop borrows early, ignore them. Modern Rust handles this automatically.
Realistic scenarios
Borrow errors often appear in methods on structs. You borrow one field, then try to mutate another. The compiler sees self as a single unit. If you borrow self.name immutably, you can't borrow self.email mutably, even though they're different fields. The borrow checker doesn't track field-level granularity for self.
struct User {
name: String,
email: String,
}
impl User {
// This function tries to validate name and update email.
// It fails because it borrows self mutably and immutably.
fn update_email(&mut self, new_email: &str) {
// Immutable borrow of self.name
let name_ref = &self.name;
// Mutable borrow of self.email
// ERROR: E0502 cannot borrow `self.email` as mutable
// because `self.name` is also borrowed as immutable.
self.email = new_email.to_string();
println!("Updating email for {}", name_ref);
}
}
The fix is to clone the data you need to read, or restructure the logic.
impl User {
fn update_email_fixed(&mut self, new_email: &str) {
// Clone the name to break the borrow.
// This allocates a new String, but it's cheap and safe.
let name_clone = self.name.clone();
// Now we can mutate self freely.
self.email = new_email.to_string();
println!("Updating email for {}", name_clone);
}
}
Another common trap is Vec reallocation. If you borrow an element, then push to the vector, the vector might need to grow. It allocates new memory, copies everything, and frees the old memory. Your borrow to the element now points to freed memory. Rust catches this.
fn main() {
let mut vec = vec![1, 2, 3];
// Borrow the first element.
let first = &vec[0];
// ERROR: E0502. Pushing might reallocate the vector.
// This would invalidate `first`.
vec.push(4);
println!("{}", first);
}
If you're fighting the borrow checker on a struct method, clone the field you need. It's usually worth the tiny allocation.
Pitfalls and error codes
Borrow errors have specific codes. Reading the code tells you exactly what went wrong.
E0502: Cannot borrow as mutable because it is also borrowed as immutable. You have a reader and a writer active at the same time. Fix the conflict. Clone the data, or restructure so the read finishes before the write.
E0507: Cannot move out of borrowed content. You tried to move a value out of a reference. References can't give up ownership. You can only move out of something you own. Fix by cloning or copying the value.
fn main() {
let s = String::from("hello");
let r = &s;
// ERROR: E0507. Cannot move out of `*r`.
// `r` is a reference. You can't take ownership through it.
let owned = *r;
}
E0382: Use of moved value. You used a value after moving it. Ownership transferred to another variable or function. Fix by cloning before moving, or borrowing instead of moving.
fn main() {
let s1 = String::from("hello");
let s2 = s1; // Move
// ERROR: E0382. `s1` was moved to `s2`.
println!("{}", s1);
}
E0596: Cannot borrow as mutable, as it is not declared mutable.
You tried to mutate a variable without mut. Fix by adding mut to the let binding.
fn main() {
let s = String::from("hello");
// ERROR: E0596. `s` is immutable.
s.push_str(" world");
}
E0716: Temporary value dropped while borrowed. Temporary values live until the end of the statement. If you borrow a temporary, the borrow tries to outlive the statement. The temporary dies. You get a dangling reference.
fn main() {
// ERROR: E0716. The String is created, borrowed, then dropped.
// `x` holds a reference to dropped data.
let x = &String::from("hello");
}
Fix by binding the value to a variable first.
fn main() {
let s = String::from("hello");
let x = &s; // Safe. `s` lives as long as `x`.
}
Convention aside: When you see a borrow error, ask: "Do I really need this reference to live this long?" Often, cloning a small value like a String or Vec is cheaper than restructuring the whole function. If the value is huge, restructure. Cloning is the escape hatch for small data.
Read the error code. E0502 means you have a conflict. Fix the conflict, don't fight the error.
Decision: borrowing vs cloning vs interior mutability
Use cloning when the value is small, like a String or Vec, and restructuring the code to shorten the borrow scope would make the logic unreadable.
Use borrowing when you need to avoid allocation and the compiler can prove the read finishes before the write starts.
Use RefCell<T> when you need to mutate data through an immutable reference in a single-threaded context, accepting the runtime check cost.
Use Cow<Borrowed> when you have a value that might be borrowed or owned, and you want to clone only if you actually modify it.
Reach for &str instead of &String when passing string slices to functions. It's more flexible and avoids unnecessary coupling.
Pick the tool that matches your data flow. If you're unsure, borrow. If the borrow checker blocks you, clone. If cloning is too expensive, rethink the design.