`|&mut:|` wants (`Copy`) upvar to be mutable when it shouldn't

[japaric]

STR

#![feature(overloaded_calls, unboxed_closures)]

use std::mem;

fn main() {
    // error: cannot assign to immutable captured outer variable in a proc
    //let n = 0u8;
    let mut n = 0u8;

    let mut f = |&mut:| {
        n += 1;
        println!("f.n = {}", n);
    };

    println!("Closure size: {}", mem::size_of_val(&f));
    f();
    f();
    f();
    println!("n = {}", n);
}

Output

Closure size: 1
f.n = 1
f.n = 2
f.n = 3
n = 0

Correct me if I'm wrong, but I think n shouldn't need to be mutable, because f captures (by value) a copy of n, and modifies its copy of n on each call. Whereas, the outer n remains unchanged.

cc @pcwalton

[bkoropoff]

A proc has the same behavior, so this isn't a difference with unboxed closures in particular. It strikes me as intentional since rust defaults to immutability, and the only place where you can specify that you want mutability is on the original binding. You can always write something like this instead:

let x = 0u;
...
let mut x_copy = x;
let f = move |&mut:| x_copy = 42;

[nikomatsakis]

The closure in the original example is capturing by reference, not by value as the description implies. In any case I added a test covering all the tests and will close this issue -- everything seems to be behaving reasonably. The one thing that surprised me is that you can mutate a variable declared as let from within a FnMut closure; it makes sense when you consider the desugaring. This seems to be the case that @japaric was initially attempting to test, and it indeed works as he predicted. I am not sure yet if this is a bug though.