为什么 HashMap::get_mut 在生命周期方面比 HashMap::get 更挑剔？

Question

我有一个struct Foo<'a>，它是&'a str 引用的包装。我想用Foos 作为键填充HashMap。这是一段 sn-p 代码 (open it in playground)：

use std::collections::HashMap;

#[derive(PartialEq, Eq, Hash)]
struct Foo<'a> {
    txt: &'a str,
}

fn main() {
    let a = "hello".to_string();
    let a2 = Foo { txt: &a };
    let b = "hello".to_string();
    let b2 = Foo { txt: &b };

    let mut hm = HashMap::<Foo, u32>::new();

    hm.insert(a2, 42);
    println!("=== {:?}", hm.get(&b2));     // prints Some(42)
    println!("=== {:?}", hm.get_mut(&b2)); // prints Some(42)

    {
        let c = "hello".to_string();
        let c2 = Foo { txt: &c };
        println!("=== {:?}", hm.get(&c2));         // prints Some(42)
        // println!("=== {:?}", hm.get_mut(&c2));  // does not compile. Why?
        // hm.insert(c2, 101);                     // does not compile, but I understand why.
    }
}

这段代码可以完美编译和运行，但是如果我取消注释最后两行代码，编译器会报错。更准确地说，它抱怨 c2 中的借来的值不够长。

对于最后一个 (insert)，这是完全可以理解的：我不能将 c2 移动到 HashMap，它的寿命比 c2 从 c 借来的数据要长。

但是，我不明白为什么倒数第二行 (get_mut) 有同样的问题：在这种情况下，借用的数据应该只在调用 get_mut 期间是必需的，它不是移入HashMap。

更令人惊讶的是，上面的get 可以完美运行（正如我所料），并且get 和get_mut 在k 参数方面具有相同的签名......

---

再挖一点之后， 我用普通引用（而不是嵌入引用的结构）重现了这个问题。

use std::collections::HashMap;

fn main() {
    let a = 42;
    let b = 42;

    let mut hm = HashMap::<&u32,u32>::new();

    hm.insert(&a, 13);
    println!("=== {:?}", hm.get(&&b));     // prints Some(13)
    println!("=== {:?}", hm.get_mut(&&b)); // prints Some(13)

    {
        let c = 42;
        println!("=== {:?}", hm.get(&&c));        // prints Some(13)
        //println!("=== {:?}", hm.get_mut(&&c));  // does not compile. Why?
    } 
}

(open in playground)

同样，取消注释最后一行会导致编译器抱怨（与上面的消息相同）。

但是，对于这个特定示例，我发现了一个有趣的解决方法：在最后一行中将 &&c 替换为 &c 解决了问题——实际上，可以在对 @987654348 的所有调用中将 && 替换为 & @ 和 get_mut。我想这与 &T 实现 Borrow<T> 有关。

我不明白在这个解决方法中究竟是什么说服了编译器做我想让它做的事情。而且我不能直接将它应用到我的原始代码中，因为我不使用 references 作为键，而是使用嵌入引用的对象，所以我无法将 && 替换为 &...

Answer 1

问题的出现是因为不可变引用在其（被引用的）类型上是可变的，而可变引用在其类型上是不变的。

Nomicon 是理解这个概念的好书。

HashMap：get 与 get_mut

进一步缩小，这是重现问题的更简单的代码：

#![allow(unused_variables)]
use std::collections::HashMap;

fn main() {
    let mut hm = HashMap::<&u32, u32>::new();    // --+ 'a
    let c = 42;                                    // |  --+ 'b
                                                   // |    |
    HashMap::<&u32, u32>::get(&mut hm, &&c);       // |    |
    // HashMap::<&u32, u32>::get_mut(&mut hm, &&c);// |    |
}                                                  // +    +

不可变的情况

考虑HashMap::get的签名：

fn get<Q: ?Sized>(&self, k: &Q) -> Option<&V>
    where K: Borrow<Q>, Q: Hash + Eq

在这种情况下，&Q 是 &&'b u32，get 的接收者是 &Self。

不可变引用的变体性质意味着 &HashMap<&'a u32, u32> 可用于需要 &HashMap<'b u32, u32> 的地方。

由于这条规则，编译器会考虑原始调用：

HashMap::<&'a u32, u32>::get(&hm, &&'b c);

相当于：

HashMap::<&'b u32, u32>::get(&hm, &&'b c);

编译器从接口推断，并且仅从接口，方法实现不会引入泄漏：编译成功。

可变情况

考虑HashMap::get_mut的签名：

fn get_mut<Q: ?Sized>(&mut self, k: &Q) -> Option<&mut V>
    where K: Borrow<Q>, Q: Hash + Eq

同样在这种情况下&Q 是&&'b u32，但get_mut 的接收者是&mut Self。

可变引用的不变性意味着 &mut HashMap<&'a u32, u32> 不能用于需要 &mut HashMap<&'b u32, u32> 的地方。

由于此规则，编译器会抛出错误，因为通过分析仅接口：

HashMap::<&'a 32, u32>::get_mut(&mut hm, &&'b c);

编译器不能排除，例如，get_mut 可能存储一个生命周期为'b 的键。

这样的键不能超过hm HashMap：编译失败。