从HashMap或Vec返回引用会导致借用持续时间超出其所处的范围吗？

Question

我有一个持续的编译错误，Rust抱怨说，当我试图可变地借用时，我有一个不可变的借用，但是不可变的借用来自另一个范围，我没有从它身上带来任何东西。

我有一些代码检查映射中的值，如果它存在，则返回它，否则它需要以各种方式改变映射。问题是我似乎找不到一种方法来除锈，让我两者都做吧，即使这两个操作是完全分开的。

下面是一些与我的代码结构相同的无意义代码，并显示了问题：

use std::collections::BTreeMap;

fn do_stuff(map: &mut BTreeMap<i32, i32>, key: i32) -> Option<&i32> {
    // extra scope in vain attempt to contain the borrow
    {
        // borrow immutably
        if let Some(key) = map.get(&key) {
            return Some(key);
        }
    }

    // now I'm DONE with the immutable borrow, but rustc still thinks it's borrowed

    map.insert(0, 0); // borrow mutably, which errors
    None
}

这错误输出：

error[E0502]: cannot borrow `*map` as mutable because it is also borrowed as immutable
  --> src/lib.rs:14:5
   |
3  | fn do_stuff(map: &mut BTreeMap<i32, i32>, key: i32) -> Option<&i32> {
   |                  - let's call the lifetime of this reference `'1`
...
7  |         if let Some(key) = map.get(&key) {
   |                            --- immutable borrow occurs here
8  |             return Some(key);
   |                    --------- returning this value requires that `*map` is borrowed for `'1`
...
14 |     map.insert(0, 0); // borrow mutably, which errors
   |     ^^^^^^^^^^^^^^^^ mutable borrow occurs here

这对我来说没有任何意义。不可变的借入如何在那个范围内存活？！匹配的一个分支通过返回退出函数，另一个分支什么也不做，离开作用域。

我以前见过这种情况，在其他变量中，我错误地将借入从范围中走私出去，但这里不是这样！

诚然，借用是通过return语句逃出作用域的，但在函数中阻止进一步借用是荒谬的——程序不可能返回并继续运行！如果我在那里返回其他内容，错误就会消失，因此我认为这就是借阅检查器被挂断的原因。这对我来说像个虫子。

不幸的是，我一直找不到任何方法来重写它而不碰到相同的错误，所以如果是这样的话，这是一个特别讨厌的错误。

Answer 1

这是一个已知的问题，将在未来的非词汇生存期迭代中解决，但目前尚未在Rust 1.57中处理。

如果您插入到正在查找的同一个密钥，我建议您改用entry API。

现在你可以加上一点低效来解决这个问题。如果效率低下是不可接受的，那么还有更深层次的解决办法。

一般的想法是添加一个布尔值，告诉您是否存在值。此布尔值不挂起引用，因此不存在借用：

use std::collections::BTreeMap;

fn do_stuff(map: &mut BTreeMap<i32, i32>, key: i32) -> Option<&i32> {
    if map.contains_key(&key) {
        return map.get(&key);
    }

    map.insert(0, 0);
    None
}

fn main() {
    let mut map = BTreeMap::new();
    do_stuff(&mut map, 42);
    println!("{:?}", map)
}

类似的情况可以通过使用元素的索引而不是引用来解决。像上面的例子一样，由于需要再次检查切片边界，这可能会带来一点低效。

而不是

fn find_or_create_five<'a>(container: &'a mut Vec<u8>) -> &'a mut u8 {
    match container.iter_mut().find(|e| **e == 5) {
        Some(element) => element,
        None => {
            container.push(5);
            container.last_mut().unwrap()
        }
    }
}

你可以写：

fn find_or_create_five<'a>(container: &'a mut Vec<u8>) -> &'a mut u8 {
    let idx = container.iter().position(|&e| e == 5).unwrap_or_else(|| {
        container.push(5);
        container.len() - 1    
    });
    &mut container[idx]
}

这些类型的示例是NLL RFC中的主要案例之一：问题案例#3：跨函数的条件控制流。

不幸的是，这个特定的案例在Rust 1.57中还没有准备好。如果您选择在夜间使用实验性的-Zpolonius功能（RUSTFLAGS=“-Zpolonius”cargo nightly check），则这些原始示例都按原样编译：

use std::collections::BTreeMap;

fn do_stuff(map: &mut BTreeMap<i32, i32>, key: i32) -> Option<&i32> {
    if let Some(key) = map.get(&key) {
        return Some(key);
    }

    map.insert(0, 0);
    None
}

fn find_or_create_five(container: &mut Vec<u8>) -> &mut u8 {
    match container.iter_mut().find(|e| **e == 5) {
        Some(element) => element,
        None => {
            container.push(5);
            container.last_mut().unwrap()
        }
    }
}

另见：

>

如何在Vec上更新或插入？

这是同样的问题，但不返回引用，它与Rust 1.32中提供的NLL实现一起工作。

即使NLL打开，循环中也会发生双重可变借用错误

这个问题只是在稍微复杂一点的情况下。

什么时候有必要绕过Rust的借货检查器？

终极逃生舱。