Closures should infer to capture by copy

[bluss]

Inspired by a common stumbling block with Iterator::flat_map.

This code does not compile:

(0..10).flat_map(|i| (0..i).map(|j| i + j))

error: `i` does not live long enough

(playground code)

The problem: i is a local variable and captured by reference in a closure we're trying to return. It's an integer, its data size is equal or smaller as a value instead of a reference.

Can rustc infer that the closure should capture i by "move" here (Copy)?

[Stebalien]

That seems a bit magical. What if i were mutable?

[bluss]

The compiler can already infer move sometimes, for example when you consume a value like this. This compiles without error:

(0..10).flat_map(|_| { let s = String::new(); Some(1).map(|_| s) });

(It's valid to return because the closure to Option::map is an FnOnce, but FnOnceness is really orthogonal to capture mode.)

I don't immediately see the issue with mutability. It works the same to the closure if a variable is captured by mutable reference or copy, you can mutate it anyway.

(0..10).flat_map(|mut i| (0..10).map(move |j| { i += j; i }));  // this is fine

[Stebalien]

I don't immediately see the issue with mutability. It works the same to the closure if a variable is captured by mutable reference or copy, you can mutate it anyway.

I was more worried about the case where something outside the closure mutates i. However, that would require a Copy type with interior mutability (which I don't think is even possible).

The compiler can already infer move sometimes, for example when you consume a value like this.

Given this, I'd have to agree. Note: "sometimes" is when the closure is FnOnce.

[arielb1]

That would be lifetime inference affecting type inference. I don't feel like this is going to happen.

[bluss]

@arielb1 That I can absolutely understand. But do you think it would have to be like that, could it not simply infer to Copy here because it can copy and preserve the exact same functionality in the closure?

[arielb1]

@bluss

But that won't help when i is not Copy.

Without nested closures, we already have a "closure may outlive the current function" error message, but it is not shown there because of laziness. This issue was already known since we had unboxed closures.