Procs don't allow capturing mutable variables

[alexcrichton]

This code fails to compile

fn foo(_: proc()) {}

fn bar(_: &mut int) {}

fn main() {
    let mut a = 3;
    do foo {
        bar(&mut a);
    }
}

with

test.rs:8:12: 8:18 error: cannot borrow immutable captured outer variable in a heap closure as mutable
test.rs:8         bar(&mut a);
                      ^~~~~~
test.rs:8:17: 8:18 error: mutable variables cannot be implicitly captured
test.rs:8         bar(&mut a);
                           ^
error: aborting due to 2 previous errors
task 'rustc' failed at 'explicit failure', /Users/alex/code/rust-opt/src/libsyntax/diagnostic.rs:101
task '<main>' failed at 'explicit failure', /Users/alex/code/rust-opt/src/librustc/lib.rs:396

Since procs are one-shot, I don't see why I can't capture the value mutably, the proc gains ownership of the type.

cc @pcwalton, @nikomatsakis

[nikomatsakis]

I agree, this error is obsolete -- the concern was code clarity. This used to be called #2152 (but I see we closed that). I think all we have to do is just remove the error in borrowck and everything else will work just fine.

[nickdesaulniers]

@nikomatsakis , see the comments in this test case. If you still believe it's ok, I'll remove that test case, and this branch of the match. Note how in the test, the shadow copied var is not mutable, which is the whole point (to be able to move mutable variables into a closure).

[nikomatsakis]

@nickdesaulniers I think it's ok -- there is a potential hazard, if people don't realize the counter is being copied, but c'est la vie. I toyed with suggesting that procs always move or something like that but I think it's more consistent to just say that they move/copy in the usual way at the time of their creation.

Note: it'd be good to test whether you can re-assign the variable in the proc as well. I imagine that should be legal (obviously it'll modify the proc's copy).

[nickdesaulniers]

Note: it'd be good to test whether you can re-assign the variable in the proc as well. I imagine that should be legal (obviously it'll modify the proc's copy).

@nikomatsakis , it looks like the proc's copy does not have the same mutability as the closed over var. For example:

fn foo() {
  let mut i = 0;
    do task::spawn {
      i += 1; // fails here
      some_func(i);
      println!("spawned {}", i)
    }
    i += 1;
    println!("original {}", i)
}

will fail to compile complaining that: cannot assign to immutable captured outer variable in a heap closure. It will work if within the closure, you say let mut i = i; Is this something that should be fixed?

[nmsmith]

I agree this needs to be fixed. For types that are moved/copied anyway, it makes no difference whether they are mutable or not when they are taken by a proc. It might stop newcomers from accidentally copying a variable, but I think it's over-the-top to make it an error for everyone if that is the only reason for making it forbidden. Speaking from experience, those error messages only make procs harder to understand.

And it looks like @nickdesaulniers has brought up another issue that should probably also be addressed.

[nikomatsakis]

On Wed, Jan 15, 2014 at 11:39:58AM -0800, Nick Desaulniers wrote:

Is this something that should be fixed?

Probably. I guess it's no loss of expressiveness, as one can always
write let mut x = x inside the proc. But I'm not sure there's a good
reason to prevent mutation.

[nickdesaulniers]

ok then I think that this should be two separate issues (one for the two issues @alexcrichton 's code example shows):

1. cannot borrow immutable captured outer variable in a heap closure as mutable
2. mutable variables cannot be implicitly captured

[nickdesaulniers]

Not sure yet how to tackle the second part.

[nikomatsakis]

@nickdesaulniers I'm not sure I understand your division into 2 parts. I guess you mean (1) cannot capture mutable variables in a proc and (2) captured mutable variables are not themselves mutable? I can help you with (2)