Common Advanced Borrow-Checker Challenges

Even in well-structured safe Rust, certain control-flow and collection access patterns interact subtly with the borrow checker (NLL — Non-Lexical Lifetimes). Understanding why these challenges occur and which standard library patterns resolve them avoids unnecessary cloning or unsafe code.

Challenge 1: Conditional Return of a Borrow vs. Fallback Insertion (HashMap::entry)

In current NLL borrow checking, if a method borrows map mutably (if let Some(v) = map.get_mut(key) { return v; }) and returns that reference out of the function, the compiler extends the mutable borrow of map across the entire function body—even into the None fallback branch where map.insert(...) needs to borrow map again!

The standard solution is using the Entry API (map.entry(key).or_insert_with(...)), which performs the lookup and fallback insertion through a single mutable borrow:

use std::collections::HashMap;

fn get_or_compute(cache: &mut HashMap<u32, String>, key: u32) -> &mut String {
    cache
        .entry(key)
        .or_insert_with(|| format!("computed-{}", key * 10))
}

fn main() {
    let mut cache = HashMap::new();
    let v1 = get_or_compute(&mut cache, 3);
    v1.push_str(" (modified)");

    println!("entry 3: {:?}", get_or_compute(&mut cache, 3));
}

entry 3: "computed-30 (modified)"

Challenge 2: Mutating Multiple Elements of a Slice Simultaneously

Indexing a slice mutably twice (&mut slice[i] and &mut slice[j]) is rejected because the compiler cannot statically prove i != j. Three safe standard library methods split a slice into guaranteed disjoint mutable borrows:

fn get_two_mut<T>(slice: &mut [T], i: usize, j: usize) -> Option<(&mut T, &mut T)> {
    if i == j || i >= slice.len() || j >= slice.len() {
        return None;
    }
    if i < j {
        let (left, right) = slice.split_at_mut(j);
        Some((&mut left[i], &mut right[0]))
    } else {
        let (left, right) = slice.split_at_mut(i);
        Some((&mut right[0], &mut left[j]))
    }
}

fn main() {
    let mut scores = [10, 20, 30, 40];
    if let Some((first, third)) = get_two_mut(&mut scores, 0, 2) {
        *first += 5;
        *third += 50;
    }
    println!("scores: {:?}", scores);
}

scores: [15, 20, 80, 40]

Challenge 3: Moving Out of a &mut T Reference (std::mem::take and std::mem::replace)

When implementing state machines (enum State) inside a &mut self method, pattern matching on *self cannot move owned fields out unless a valid state is immediately left in *self. Using std::mem::replace(self, State::Empty) or std::mem::take(self) moves the old state out by value so you can destructure and move its owned fields freely:

use std::mem;

#[derive(Debug, Default)]
enum ConnectionState {
    #[default]
    Closed,
    Handshaking {
        pending_packets: Vec<String>,
    },
    Established {
        backlog: Vec<String>,
    },
}

impl ConnectionState {
    fn finish_handshake(&mut self) {
        // Move the current state out by replacing `*self` temporarily with `Closed`:
        let prev = mem::take(self);
        *self = match prev {
            ConnectionState::Handshaking { pending_packets } => {
                // `pending_packets` is moved by value with zero cloning!
                ConnectionState::Established {
                    backlog: pending_packets,
                }
            }
            other => other,
        };
    }
}

fn main() {
    let mut state = ConnectionState::Handshaking {
        pending_packets: vec![String::from("SYN"), String::from("ACK")],
    };
    state.finish_handshake();
    println!("transitioned state: {:?}", state);
}

transitioned state: Established { backlog: ["SYN", "ACK"] }

Challenge 4: Reborrowing &mut T Across Loop Iterations

Because &mut T is not Copy, passing a mut_ref: &mut T to a helper function inside a loop works via automatic reborrowing (&mut *mut_ref), provided the helper does not return a reference that escapes into the next iteration of the loop.