Quick answer
Two &mut references to the same value are alive at once. Rust requires a mutable borrow to be exclusive. End the first borrow before taking the second (since NLL a borrow ends at its last use, so reordering often fixes it), or use a splitting API like split_at_mut to get disjoint borrows.
The exact error string
error[E0499]: cannot borrow `v` as mutable more than once at a time
--> src/main.rs:4:14
|
3 | let a = &mut v;
| ------ first mutable borrow occurs here
4 | let b = &mut v;
| ^^^^^^ second mutable borrow occurs here
5 | a.push(1);
| - first borrow later used hereHow to read it
Rust marks three lines: "first mutable borrow occurs here", "second mutable borrow occurs here" (the rejected line), and "first borrow later used here". That last line is the key — the first borrow is still live because you use it after the second. If you can move the first borrow's last use earlier, the conflict disappears.
Cause 1: two overlapping &mut
let mut v = vec![1, 2, 3];
let a = &mut v;
let b = &mut v; // ❌ second &mut while a is still used below
a.push(4);
b.push(5);
// ✅ finish with the first borrow before taking the second
let mut v = vec![1, 2, 3];
{ let a = &mut v; a.push(4); } // a's scope ends here
let b = &mut v; b.push(5);Cause 2: borrowing inside a loop you also mutate
let mut v = vec![1, 2, 3];
let first = &mut v[0];
for x in &mut v { *x += 1; } // ❌ v already mutably borrowed by `first`
*first = 0;
// ✅ don't hold the element borrow across the loop
let mut v = vec![1, 2, 3];
for x in &mut v { *x += 1; }
v[0] = 0;Cause 3: mutating two parts of the same collection
let mut v = vec![1, 2, 3, 4];
let left = &mut v[0];
let right = &mut v[3]; // ❌ compiler can't prove these are disjoint
*left += *right;
// ✅ split into non-overlapping halves
let (a, b) = v.split_at_mut(2);
a[0] += b[1];When interior mutability is the right tool
use std::cell::RefCell;
let cell = RefCell::new(vec![1, 2, 3]);
cell.borrow_mut().push(4); // checked at RUNTIME, panics on overlap
cell.borrow_mut().push(5); // ok: previous borrow already droppedUse RefCell only when you truly need interior mutability (shared owners, graph nodes), not to paper over code that could be restructured — it trades a compile error for a possible runtime panic.
Common causes at a glance
| Situation | Why E0499 | Fix |
|---|---|---|
two &mut in a row | first still used later | scope/sequence the borrows |
| element borrow + loop | collection borrowed twice | drop the element borrow first |
| two indices of a Vec | can't prove disjoint | split_at_mut |
| two struct fields | whole struct borrowed | destructure into field &mut |
| shared owners | need aliasing + mutation | RefCell / Rc<RefCell> |
Debugging checklist
- ✓ Find "first borrow later used here" — can that use move earlier?
- ✓ Wrap the first borrow in a
{ }block to end it sooner - ✓ Two parts of one Vec/slice? Use
split_at_mut/split_first_mut - ✓ Two struct fields? Destructure instead of borrowing the whole struct
- ✓ Genuinely need aliased mutation? Reach for
RefCelldeliberately
Frequently Asked Questions
What does E0499 'cannot borrow as mutable more than once' mean?
Two &mut references to the same value are alive at the same time. Rust guarantees a mutable borrow is exclusive — at most one &mut may exist for a value at any moment — so the second one is rejected. End the first borrow before taking the second.
Why does Rust only allow one mutable borrow?
Exclusive mutable access is how Rust prevents data races and aliasing bugs at compile time. If two &mut pointed at the same data, a write through one could invalidate the other. The rule is: many &T (shared, read-only) OR one &mut T (exclusive), never both.
How does non-lexical lifetimes (NLL) affect E0499?
Since NLL, a borrow ends at its last use, not at the end of the block. So storing the first &mut in a variable you keep using is what extends it. Often just reordering code so the first borrow's last use comes before the second fixes E0499 with no other change.
How do I mutate two parts of the same Vec or struct?
Use a splitting API: split_at_mut / split_first_mut for slices and Vecs, or destructure a struct into separate &mut fields. These hand you disjoint mutable references the compiler can prove don't overlap.
When should I use RefCell instead?
RefCell<T> moves the single-mutable-borrow check from compile time to run time (panicking on violation). Use it only when you genuinely need interior mutability — e.g., shared graph nodes — not to silence E0499 in code that can be restructured.
What is the difference between E0499 and E0502?
E0499 is two mutable borrows at once. E0502 is mixing a mutable borrow with a shared (immutable) borrow at the same time. Both come from the same rule — &mut must be exclusive — just different combinations.
More language & runtime errors
Browse the full reference for Rust, Go, Node.js, Python, and database errors — exact message, cause, and fix.