Understanding Rust Closures: Why do they Continuously Hold Mutable References?

I'm currently learning about closures in Rust and am trying to understand why they continuously hold references until their last use.

Consider the following code:

fn borrows_mutably_func(list: &mut Vec<i32>) {
    list.push(4);
}

fn main() {
    let mut list = vec![1, 2, 3];
    println!("Before defining: {:?}", list);


    borrows_mutably_func(&mut list);
    println!("After calling first (func): {:?}", list);
    borrows_mutably_func(&mut list);
    println!("After calling second (func): {:?}", list);
    
    
    let mut borrows_mutably_closure = || list.push(5);
    
    borrows_mutably_closure();
    println!("After calling first (closure): {:?}", list);
    borrows_mutably_closure();
    println!("After calling second (closure): {:?}", list);
}

In this code, borrows_mutably_func is a function that mutates list by adding an element to it. This function can be called multiple times without any issues. However, when I try to replicate this behavior using a closure (borrows_mutably_closure), the code fails to compile.

From my understanding, this issue arises because the closure captures list by a mutable reference and holds onto this reference continuously until its last use. This differs from the function, which releases the reference after each call.

My question is: Why does Rust enforce this behavior for closures? Why can't the closure release the mutable reference after its first use (like the function does) and re-acquire it just before its second use? This approach seems more intuitive to me, as it would allow the closure to behave similarly to the function without continuously holding the mutable reference. Any insights would be greatly appreciated!

> My question is: Why does Rust enforce this behavior for closures? Why can't the closure release the mutable reference after its first use (like the function does) and re-acquire it just before its second use?

Because it's not feasible. A closure is, in essence, a structure which stores all the things it closes over. So here on line 13 you essentially instantiate a structure similar to:

struct BorrowsMutablyClosure<'a> {
    list: &'a mut Vec<i32> 
}
impl BorrowsMutablyClosure<'_> {
    fn call_mut(&mut self) {
        self.list.push(5);
    }
}

The function is a completely different case, you pass in the reference during each call, that's how the reference is available to the function.

You can do the exact same thing with the closure, if you pass in the reference as parameter, it won't need to store the reference internally.

> This approach seems more intuitive to me

But it makes no sense. The mutable reference is necessarily outstanding from the instant you create the closure to the instant the closure is destroyed, since the closure needs to store it. There is no mecanism for the closure to release then re-acquire a mutable reference.

The closure is actually behaving the same as a mutable reference would ─ the difference is that in the first example you are not creating a mutable reference and then "re-acquiring" it, you are creating two separate mutable references, neither of which has a lifetime overlapping another use of list.

If you instead create one mutable reference whose lifetime spans both calls, you get the same error as the second example (with the closure):

let list_ref = &mut list;

borrows_mutably_func(list_ref);
// [E0502]: cannot borrow `list` as immutable because it is also borrowed as mutable
println!("After calling first (func): {:?}", list);
borrows_mutably_func(list_ref);

Basically, Rust doesn't keep track of whether a mutable reference is currently "released" when it is still live; so long as the mutable reference is still alive, the borrow checker requires that the same value is not accessed otherwise, even if that mutable reference could be "released" and then "reacquired".

To satisfy the borrow checker you will have to explicitly release and reacquire the mutable reference by using two different mutable references with separate lifetimes, like your first example does.