Why does unrap_or () continue to take over?

Question

Trying to compile:

fn main() { let mut vec = vec![1, 2, 3]; let four: &mut u32 = borrow_or_add(&mut vec, 4); } fn borrow_or_add(vec: &mut Vec<u32>, val: u32) -> &mut u32 { vec.iter_mut().find(|v| **v == val).unwrap_or({ vec.push(val); vec.last_mut().unwrap() }) } 

Playground

... gives the following result:

 q.rs:8:9: 8:12 error: cannot borrow `*vec` as mutable more than once at a time q.rs:8 vec.push(val); ^~~ q.rs:7:5: 7:8 note: previous borrow of `*vec` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `*vec` until the borrow ends q.rs:7 vec.iter_mut().find(|v| **v == val).unwrap_or({ ^~~ q.rs:12:2: 12:2 note: previous borrow ends here q.rs:6 fn borrow_or_add(vec: &mut Vec<u32>, val: u32) -> &mut u32 { ... q.rs:12 } ^ q.rs:10:9: 10:12 error: cannot borrow `*vec` as mutable more than once at a time q.rs:10 vec.last_mut().unwrap() ^~~ q.rs:7:5: 7:8 note: previous borrow of `*vec` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `*vec` until the borrow ends q.rs:7 vec.iter_mut().find(|v| **v == val).unwrap_or({ ^~~ q.rs:12:2: 12:2 note: previous borrow ends here q.rs:6 fn borrow_or_add(vec: &mut Vec<u32>, val: u32) -> &mut u32 { ... q.rs:12 } ^ q.rs:10:9: 10:12 error: cannot borrow `*vec` as mutable more than once at a time q.rs:10 vec.last_mut().unwrap() ^~~ q.rs:7:5: 7:8 note: previous borrow of `*vec` occurs here; the mutable borrow prevents subsequent moves, borrows, or modification of `*vec` until the borrow ends q.rs:7 vec.iter_mut().find(|v| **v == val).unwrap_or({ ^~~ q.rs:12:2: 12:2 note: previous borrow ends here q.rs:6 fn borrow_or_add(vec: &mut Vec<u32>, val: u32) -> &mut u32 { ... q.rs:12 } ^ 

As far as I know, the body unwrap_or() cannot refer to the vec borrowing mentioned, so why is it not removed from scope? Is there an elegant way to implement this feature? In fact, I cannot find a way to successfully do this without using two passes and a bool (i.e. contains() ).

Answer 1

The loan is active, at least for the entire application. Unfortunately, the usual solution to pulling Option into a separate statement will not help, since it will still contain a mutable link (in Some ), which forces the vector to also expand. This seems inevitable when using find() . The compiler is concerned that the pointer to the Vector repository is floating somewhere and might be invalid by clicking on the vector (which could lead to redistribution). This includes not only the pointer in the returned Option , but also those that can be made inside one of these functions. This would be a very urgent problem, if not for the fact that there are no "hidden" pointers, and you only click when Option not a pointer. The life cycle system is not good enough to capture this fact, and I see no easy way to fix it or get around it.

What you can do is use position to find the index:

 fn borrow_or_add(vec: &mut Vec<u32>, val: u32) -> &mut u32 { match vec.iter().position(|&v| v == val) { Some(i) => &mut vec[i], None => { vec.push(val); vec.last_mut().unwrap() } } } 

Note that indexes in vectors are essentially distinguished pointers. They may start to refer to the wrong element if the vector changes, although they cannot become dangling when redistributing, and invalid indices (larger than the largest valid index) will cause panic, not memory. However, getting the index from position , and then indexing it, is true only because the vector does not change (substantially) between them.

Answer 2

The problem is that you know, by virtue of its semantics, that vec.iter_mut().find().unwrap_or() will ignore anything about the vec from which it comes. However, the compiler does not know about this. Indeed, a chain of method calls can very well store the value coming from the iterator, right up to the closure caused by unwrap_or() . See this common scenario, which has an analog in your example:

 let mut vec: Vec<i32> = vec![3, 2, 5]; vec.iter().map(|&i| { vec.push(i+1) }).last(); 

Here vec.iter_mut().find().unwrap_or() simply replaced with vec.iter().map() . And, as you can see, the values ​​from vec can be borrowed during a method call. In this last example, it is obvious that vec.push(i+1) will invalidate the iterator, so the compiler prevents it.