Why does the compiler not complain that an iterator moved to a for loop is immutable?

Question

I am reading the second edition of the Rust Book and I found the following sample in the iterators section:

let v1 = vec![1, 2, 3];
let v1_iter = v1.iter();    
for val in v1_iter {
    println!("Got: {}", val);
}

Why does the compiler not complain that v1_iter is immutable? The book says the for loop took ownership of v1_iter and made it mutable behind the scenes, but can you convert an immutable variable to mutable?

Answer 1

The book says the for loop took ownership of v1_iter and made it mutable behind the scenes,

Exactly, and one can make an even simpler example:

let v = vec![1,2,3];
let mut x = v;
x.push(0);

Note that v and x are separate variable bindings: for as long as the variable v retained our 3-element vector, the contract of the variable was that the vector will not be mutated. However, the vector was moved to x, which declares that mutability is acceptable. The same applies to function calls:

fn foo(mut x: Vec<i32>) {
    x.push(0);
}

let v = vec![1,2,3];
foo(v);

This is safe because only one of the variables owns the vector at any point of its lifetime. Once v was moved to x, v can no longer be used. Likewise, in your code, v1_iter can no longer be used after the for loop.

but can you convert an immutable variable to mutable?

Both snippets work because the value was moved to a new variable declared as mut. However, once a variable is declared as immutable (or mutable), that variable stays so for all of its lifetime, and that cannot be changed. So the answer is no, but ownership semantics enable moving values across variables with different mutability guarantees.

See also:

• What's the difference between placing "mut" before a variable name and after the ":"?

• Why does Rust allow mutation through a reference field using an immutable binding?