Mutable references and exclusive access

A correction operation should change the original student mark rather than return an unrelated copy. A mutable reference provides access to update a borrowed value. Rust checks that this access does not overlap with conflicting uses, so the caller can see exactly when mutation is allowed.

&mut score borrows the value mutably. Inside the function, *score dereferences that reference to reach the integer. Ordinary references to the same value must not be used in conflict with a live mutable borrow. Borrow lifetimes are often shorter than the enclosing block and can end after their last use.

Connect this idea with slices and reference lifetimes and channels, arc and mutex.

Save the complete source as main.rs in the Rust environment. No standard input is needed.

Rust 2024 · complete program

fn correct(score: &mut i32) { *score += 8; }
fn main() {
  let mut score = 72;
  let before = &score;
  println!("Before: {before}");
  correct(&mut score);
  println!("After: {score}");
}

Expected output

Before: 72
After: 80

Follow the execution

The shared borrow is last used in the first print. The later correction can therefore borrow score mutably, change 72 to 80 and finish. The final print observes the updated integer after that mutable borrow ends.

Try the complete program in the Rust compiler. For tests, Cargo commands and local files, use the specified local environment.

Your task: Why would printing before again after correct create a borrowing conflict?

Rust 2024 · complete program

fn correct(score: &mut i32) { *score += 8; }
fn main() {
  let mut score = 72;
  let before = &score;
  println!("Before: {before}");
  correct(&mut score);
  println!("After: {score}");
}

Worked answer

It would require the earlier shared borrow to remain in use across the mutable correction. Move its last use before the correction or obtain a new shared reference afterward.

The rule concerns overlapping access to the same data, not a blanket ban on all references in a program. Distinct fields can sometimes be borrowed separately. Exclusive borrowing alone does not implement a thread-safe shared counter; synchronization types have separate contracts.

It would require the earlier shared borrow to remain in use across the mutable correction. Move its last use before the correction or obtain a new shared reference afterward. The rule concerns overlapping access to the same data, not a blanket ban on all references in a program.

Further reading: the official Rust Book on mutable references and exclusive access.