Reading a mutable ref through another ref shortens its lifetime?

help
1

Hi,

Consider the following code:

struct S<'a> {
    a: &'a u32,
    a_mut: &'a mut u32,
}
fn get_ref_from_ref<'s, 'a>(s: &'s S<'a>) -> &'a u32 {
    s.a
}
fn get_ref_from_mut_ref<'s, 'a>(s: &'s S<'a>) -> &'a u32 {
    s.a_mut // <- Error: function was supposed to return
}           // data with lifetime `'a` but it is returning
            // data with lifetime `'s`

(Playground)

When I compile, I get:

error: lifetime may not live long enough
 --> src/lib.rs:9:5
  |
8 | fn get_ref_from_mut_ref<'s, 'a>(s: &'s S<'a>) -> &'a u32 {
  |                         --  -- lifetime `'a` defined here
  |                         |
  |                         lifetime `'s` defined here
9 |     s.a_mut
  |     ^^^^^^^ function was supposed to return data with lifetime `'a` but it is returning data with lifetime `'s`

This surprised me and I don't understand a few things here:

  1. In both cases, I'm clearly returning a reference with lifetime 'a, but in the mutable case it gets converted to 's for some reason. Why does this happen in the mutable case and not in the immutable case?
  2. Is there a name for this behavior, something I read more about in the book/reference/nomicon etc?
  3. Is the function get_ref_from_mut_ref() actually incorrect? In other words, if the function compiled, is there an example where it would it would violate Rust constrains?

Thanks :slight_smile:

2

Immutable, shared references implement Copy. If you have an &'a u32, you can get another &'a u32 just like copying any other type.

Mutable, exclusive references do not implement Copy. They cannot, because if they did, they would no longer be exclusive. Or from a slightly different angle, the 'a in &'a mut u32 means roughly “you may mutate the u32 for as long as ’a”, which is certainly incompatible with an &'a u32 existing.

Mutable references do, however, support reborrowing, which is where the mutable reference becomes itself borrowed and you get a new mutable or immutable reference to its referent or one of its referent’s parts. That's what happened in get_ref_from_mut_ref. Reborrowing from the mutable reference acts a lot like borrowing a struct field or such: the borrow is valid for as long as the reference to the struct or reference is, in this case 's.

Reborrowing is implicit, just like copying, and you're probably using it many times without noticing. In particular, every time you use a mutable reference twice in the same function, you are reborrowing it the first time, to create a dependent mutable reference that has a shorter lifetime which does not conflict with the lifetime of the second usage. Sometimes in generic code you can find you need to do this explicitly, writing &mut *some_ref.

The problem is “mutable references are exclusive”. The behavior you are encountering is “reborrowing”. Unfortunately, the official documentation on reborrowing is basically nonexistent.

If it compiled, you could use it to get an &'a u32 that coexisted with a usable &'a mut u32, thus violating immutability and exclusivity.

5 Likes
3

If this were allowed (and if you force it through using unsafe), you get the following classic shared mutability bug:

fn main() {
    let x: u32 = 1;
    let mut y: u32 = 2;
    let s = S { a: &x, a_mut: &mut y };
    let p1 = get_ref_from_mut_ref(&s);
    let p2 = get_ref_from_mut_ref(&s);

    dbg!(p1, p2);
    *s.a_mut += 1;
    dbg!(p1, p2);
}

This first prints 2s and then suddenly 3s. If you run it under Miri, it detects the undefined behavior.

2 Likes
4

@kpreid Thanks for the detailed response, that completely clarifies it. I've heard about reborrowing but I didn't internalize it yet, so it's helpful to encounter it in my own example. I also really appreciate the wider context you have given in your answer.

I guess I missed the root cause[1] because reborrowing added a layer of implicit behavior, which made the error more cryptic from my beginner's perspective. Do I understand correctly that if reborrowing didn't exist, the error would have been something like "cannot borrow a_mut as immutable because it is also borrowed as mutable"?

Thanks for demonstrating this! Very interesting

  1. Creating an shared reference from an exclusive one, which is like the first thing you're told when you're learning references. ↩︎

5

No, if reborrowing didn't exist, then you would be trying to move out of a reference, and the error would probably reflect that.

2 Likes
6

If reborrowing did not exist at all, mutable references would be nearly impossible to make use of. Any time you write &self.foo or &mut self.foo in a method with &mut self in the signature, that's another sort of reborrow.

If reborrowing existed but was not implicit for mutable references, you might get a type error like “expected &u32, found &mut u32”, and you'd have to write &*s.a_mut to get the conversion.

Or maybe not. It’s hard to say exactly because reborrowing is so pervasive in how mutable references are actually used.

1 Like
7

I've written a little about reborrowing here, the next few pages after that, and here.

The closest thing to official documentation which I'm aware of is the NLL RFC, but it's quite low-level and dense.

2 Likes
8

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.