Why is HashMap::get_mut more picky than HashMap::get regarding lifetimes?

Question

I have a struct Foo<'a> which is a wrapper around &'a str references. And I want to populate a HashMap with Foos as keys. Here is a snippet of code (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.
    }
}

This code compiles and runs perfectly, but the compiler complains if I uncomment the two last lines of code. More precisely, it complains about the borrowed value in c2 not living long enough.

For the last one (insert), this is perfectly understandable: I can not move c2 into the HashMap, which lives longer than data borrowed by c2 from c.

However, I don't understand why the second-to-last line (get_mut) has the same problem: in that case, the borrowed data should only be necessary during the call to get_mut, it is not moved into the HashMap.

This is all the more surprising that the get above works perfectly (as I expected), and that both get and get_mut have identical signatures when it comes to the k parameter...

---

After digging a little more, I reproduced the problem with plain references (instead of a struct embedding a reference).

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)

Again, uncommenting the last line causes the compiler to complain (same message as above).

However, I found an interesting workaround for this particular example: replacing &&c by &c in the last line solves the problem -- actually, one can replace && by & in all calls to get and get_mut. I guess this has to do with &T implementing Borrow<T>.

I don't understand precisely what, in this workaround, convinces the compiler to do what I want it to do. And I can not apply it directly to my original code, because I don't use references as keys, but objects embedding references, so I can not replace && by &...

Answer 1

The problem arises because an immutable reference is variant over its (referenced) type whereas a mutable reference is invariant over its type.

A great read for understanding the concept is the Nomicon.

HashMap: get versus get_mut

Shrinking further down, this is a simpler code reproducing the problem:

#![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);// |    |
}                                                  // +    +

The immutable case

Consider the signature of HashMap::get:

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

In this case &Q is &&'b u32 and get's receiver is &Self.

The variant nature of immutable references implies that a &HashMap<&'a u32, u32> can be used where a &HashMap<'b u32, u32> is required.

Thanks to this rule, the compiler considers the original invocation:

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

equivalent to:

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

The compiler infers from the interface, and only from the interface, that the method implementation can not introduce leaks: compilation succeeds.

The mutable case

Consider the signature of HashMap::get_mut:

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

Also in this case &Q is &&'b u32, but get_mut's receiver is &mut Self.

The invariant nature of mutable references implies that a &mut HashMap<&'a u32, u32> can not be used where a &mut HashMap<&'b u32, u32> is expected.

Thanks to this rule the compiler throws an error because by analyzing only the interface:

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

the compiler can not exclude, for example, that get_mut might store a key with lifetime 'b.

Such a key can not outlive the hm HashMap: compilation fails.