Let's just go over what it means for something to be borrowed again, because this is touching on some subtle details. There's also the fact that a reference to something is sometimes called "a borrow of that thing", but in the following I will try to consistently use "reference" to talk about references.
Let's define what I mean when I say "a borrow". It consists of two things:
- Some variable that has become borrowed.
- A section of code in which the variable is borrowed. This is called the lifetime of the borrow.
Now, creating a borrow also gives you a reference to the variable you borrowed, but this reference is ultimately a separate thing from the borrow itself. They are however still tied closely together: this reference is only valid within the borrow, and the compiler enforces this by making the lifetime of the borrow part of the type of this reference. That said, you are allowed to throw away a reference before the lifetime ends.
Now the question becomes: What influences the size of the lifetime? There are a few things:
- Using the borrowed variable inside the lifetime of the borrow is only allowed if it is consistent with the type of borrow.
- Using something (e.g. a reference, but could also be
Data<'a>) annotated with the lifetime is only allowed inside the lifetime.
The compiler will try to figure out what the lifetime should be by looking at uses of the two kinds above and using them to create a list of constraints on the lifetime. Note that immutable and mutable borrows have different requirements: An immutable borrow is allowed to overlap with another immutable borrow of the same variable, but mutable borrows may not overlap with any other borrow of the same variable.
For example:
let mut x = "abc".to_string();
let y = &mut x; // a mutable borrow of x starts here
println!("{}", x); // x is used here
In this case it knows that the borrow of x starts on the second line, and it knows that since x was used on line three, the mutable borrow cannot be active on line three. There exists a lifetime consistent with these constraints: The lifetime that starts and ends on line two. However in this case:
let mut x = "abc".to_string();
let y = &mut x; // a borrow of x starts here
println!("{}", x); // x is used here
println!("{}", y); // x must still be borrowed here
In this case we have the constraint that the lifetime of the borrow must have finished at line three, but the use of y on line four means that, due to the fact that the lifetime of the borrow is part of the type of y, that the lifetime must still be valid on line four. There is no possible choice of lifetime that satisfies both constraints, so you get a compile error.
In this example:
let x = "abc".to_string();
let y = &x; // a borrow of x starts here
println!("{}", x); // x is used here
println!("{}", y); // but the borrow is still active here
In this case we have no compile error, but this is because both uses of x only borrow x immutably, and immutable borrows are allowed to overlap.
Let's go back to the situation in question. I will first address the version that compiles:
trait Bar {
fn bar<'a>(&'a self, _: &'a mut u8) {}
}
struct Foo;
impl Bar for Foo {}
fn foo() {
let x = Foo;
let ref mut y = 5;
x.bar(y); // Both x and y are borrowed in order to perform this call
x;
y;
}
Well let's see what constraints apply on the two borrows that occurs when we call bar. The first thing is that bar requires that the lifetimes on the two references must be equal. Now, you may notice that y already has type &'l mut u8, which has an lifetime 'l that is part of the type. However, this does not necessarily mean that the lifetime of the mutable reference that bar receives is 'l, because the compiler might implicitly reborrow the mutable reference.
Reborrowing a mutable reference means that the reference itself is now borrowed. Note that the mutable reference was itself originally created by borrowing some third variable, so you actually have several borrows on top of each other, each with shorter and shorter lifetimes.
So by reborrowing y and creating something with a very short lifetime, and additionally doing the same to x, we can produce two references of a very short lifetime, and this common lifetime is so short that it ends before the use of x and y that follows.
Now for the version that does not compile. We have a function with this signature:
fn bar<'a, 'b>(&'a self, _: &'b mut Data<'a>)
Note that I have inserted an extra lifetime which was elided in the original version. In this case the lifetimes that must be equal is the one on x, and the one that is a generic parameter to Data.
fn foo() {
let x = Foo;
let ref mut y = Data(&5);
x.bar(y);
x;
y.0;
}
The generic parameter refers to the lifetime found on the immutable reference &5. In this case, since this immutable reference is stored inside y, it must obviously be valid until y no longer exists. The thing is that reborrowing does not change 'a. It changes 'b. So since the compiler does not have a mechanism of making the lifetime on &5 shorter, and since it must be equal to the lifetime on the reference to x created in order to call bar, the lifetime on this reference to x must extend until y no longer exists.
As for the fact that bar does not actually use the references, well that doesn't matter. You are allowed to throw away the reference before the lifetime ends.
Note that had bar taken an immutable reference to Data instead, it would compile. This is because immutable and mutable references are different, and you can actually shorten the inner 'a lifetime when the reference is immutable. You can read more about why here.