警告：我是从我没有的专业知识水平说话的。 鉴于这篇文章的长度，我可能错误了很多次。 
 
 
 
 
 TL; DR：顶级价值的生存期是逆变的。 参考值的寿命是不变的。 
 
 
 介绍问题 
 
 你可以通过将VecRef<'a>替换&'a mut T VecRef<'a>显着简化你的例子。 
 
 此外，应该删除main ，因为与某些特定的生命实例相比，讨论函数的一般行为更完整。 
 
 而不是VecRefRef的构造函数，让我们使用这个函数： 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}
 
 在我们进一步研究之前，了解生命如何在Rust中隐式生成是很重要的。 当一个指针指向另一个显式注释的名称时，会发生一次生命强制。 这允许的最明显的事情是缩短顶级指针的生命周期。 因此，这不是一个典型的举措。 
 
 
 
 除此之外：我说“明确注释”，因为在像let x = y或fn f<T>(_: T) {}这样的隐式情况下，再借贷似乎不会发生 。 目前还不清楚这是否是有意的。 
 
 
 那么完整的例子就是 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 这给出了同样的错误： 
 
<anon>:6:22: 6:31 error: cannot infer an appropriate lifetime for automatic coercion due to conflicting requirements
<anon>:6     use_same_ref_ref(reference);
                              ^~~~~~~~~
 
 一个微不足道的修复 
 
 显然，人们可以通过这样做来解决它 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a>(reference: &'a mut &'a mut ()) {
    use_same_ref_ref(reference);
}
 
 因为签名现在在逻辑上是相同的。 但是，不明显的是为什么 
 
let mut val = ();
let mut reference = &mut val;
let ref_ref = &mut reference;

use_ref_ref(ref_ref);
 
 能够产生&'a mut &'a mut () 。 
 
 一个不太重要的修复 
 
 可以改为执行'a: 'b 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a: 'b, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 这意味着外部参照的寿命至少与内部参照的寿命一样大。 
 
 这并不明显 
 
 
 
 为什么&'a mut &'b mut ()不能转换为&'c mut &'c mut () ，或者 
 
 
 这是否比&'a mut &'a mut ()更好。 
 
 
 我希望回答这些问题。 
 
 一个不确定的 
 
 声明'b: 'a不能解决问题。 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a, 'b: 'a>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 另一个更令人惊讶的修复 
 
 使外部引用immutable可以解决问题 
 
fn use_same_ref_ref<'c>(reference: &'c &'c mut ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 而更令人惊讶的不修复！ 
 
 使内部参考不可变根本没有帮助！ 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a mut &'b ()) {
    use_same_ref_ref(reference);
}
 
 
 但为什么？？！ 
 
 原因是... 
 
 坚持下去，首先我们讨论差异 
 
 计算机科学中两个非常重要的概念是协变和逆变 。 我不打算使用这些名称（我会非常明确地指出我要投哪些东西），但这些名称对于搜索互联网仍然非常有用。 
 
 理解方差的概念非常重要，然后才能理解这里的行为。 如果您已经参加了涵盖此课程的大学课程，或者您可以从其他方面记住它，那么您处于良好的位置。 不过，您仍然可以欣赏将这个想法与生活时间联系起来的帮助。 
 
 简单的情况 - 一个正常的指针 
 
 用一个指针考虑一些堆栈位置： 
 
    ║ Name      │ Type                │ Value
 ───╫───────────┼─────────────────────┼───────
  1 ║ val       │ i32                 │ -1
 ───╫───────────┼─────────────────────┼───────
  2 ║ reference │ &'x mut i32         │ 0x1
 
 堆栈向下生长，所以reference堆栈位置是在val之后创建的，并且会在val之前被移除。 
 
 考虑你的确如此 
 
let new_ref = reference;
 
 要得到 
 
    ║ Name      │ Type        │ Value  
 ───╫───────────┼─────────────┼─────── 
  1 ║ val       │ i32         │ -1     
 ───╫───────────┼─────────────┼─────── 
  2 ║ reference │ &'x mut i32 │ 0x1    
 ───╫───────────┼─────────────┼─────── 
  3 ║ new_ref   │ &'y mut i32 │ 0x1    
 
 什么样的生命对'y有效？ 
 
 考虑两个可变指针操作： 
 
 
 
 读 
 
 
 写 
 
 
 Read阻止'y增长，因为'x引用只能保证对象在'x范围内保持活动状态。 但是， read并不能防止'y缩小，因为当指向的值处于活动状态时，任何读取都会导致独立于生命周期'y 。 
 
 写入防止'y也增长，因为不能写入无效的指针。 但是， 写入不会阻止'y的缩小，因为对指针的任何写入都会将该值复制到其中，从而使得它的生命周期'y不变。 
 
 困难的情况 - 一个指针指针 
 
 考虑一下带指针指针的堆栈位置： 
 
    ║ Name      │ Type                │ Value  
 ───╫───────────┼─────────────────────┼─────── 
  1 ║ val       │ i32                 │ -1     
 ───╫───────────┼─────────────────────┼─────── 
  2 ║ reference │ &'a mut i32         │ 0x1    
 ───╫───────────┼─────────────────────┼─────── 
  3 ║ ref_ref   │ &'x mut &'a mut i32 │ 0x2    
 
 考虑你的确如此 
 
let new_ref_ref = ref_ref;
 
 要得到 
 
    ║ Name        │ Type                │ Value  
 ───╫─────────────┼─────────────────────┼─────── 
  1 ║ val         │ i32                 │ -1     
 ───╫─────────────┼─────────────────────┼─────── 
  2 ║ reference   │ &'a mut i32         │ 0x1    
 ───╫─────────────┼─────────────────────┼─────── 
  3 ║ ref_ref     │ &'x mut &'a mut i32 │ 0x2    
 ───╫─────────────┼─────────────────────┼─────── 
  4 ║ new_ref_ref │ &'y mut &'b mut i32 │ 0x2    
 
 现在有两个问题： 
 
 
 
 什么样的生命对'y有效？ 
 
 
 什么样的生命对'b有效？ 
 
 
 让我们首先考虑y与两个可变指针操作： 
 
 
 
 读 
 
 
 写 
 
 
 Read阻止'y增长，因为'x引用只能保证对象在'x范围内保持活动状态。 但是， read并不能防止'y缩小，因为当指向的值处于活动状态时，任何读取都将导致独立于生存期'y 。 
 
 写入防止'y也增长，因为不能写入无效的指针。 但是， 写入并不能防止'y缩小，因为对指针的任何写入都会将值复制到其中，从而使得它的生命周期'y不变。 
 
 这和以前一样。 
 
 现在，考虑两个可变指针操作 
 
 Read阻止'b增长，因为如果要从外部指针中提取内部指针，您可以在'a过期后读取它。 
 
 写防止'b也增长，因为如果要从外部指针中提取内部指针，您可以在'a过期后写入它。 
 
 由于这种情况，一起读写可以防止'b缩小， 
 
let ref_ref: &'x mut &'a mut i32 = ...;

{
    // Has lifetime 'b, which is smaller than 'a
    let new_val: i32 = 123;

    // Shrink 'a to 'b
    let new_ref_ref: &'x mut &'b mut i32 = ref_ref;

    *new_ref_ref = &mut new_val;
}

// new_ref_ref is out of scope, so ref_ref is usable again
let ref_ref: &'a mut i32 = *ref_ref;
// Oops, we have an &'a mut i32 pointer to a dropped value!
 
 Ergo， 'b不能缩小，它不能从'a ，因此'a == 'b准确地增长。 
 
 好的，这是否解决了我们的问题？ 
 
 记住代码？ 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 当您调用use_same_ref_ref ，会尝试进行use_same_ref_ref 
 
&'a mut &'b mut ()  →  &'c mut &'c mut ()
 
 现在注意'b == 'c因为我们讨论了方差。 因此我们实际上是在铸造 
 
&'a mut &'b mut ()  →  &'b mut &'b mut ()
 
 外面的&'a只能收缩。 为了做到这一点，编译器需要知道 
 
'a: 'b
 
 编译器不知道这一点，所以编译失败。 
 
 我们其他的例子呢？ 
 
 第一个是 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a>(reference: &'a mut &'a mut ()) {
    use_same_ref_ref(reference);
}
 
 而不是'a: 'b ，编译器现在需要'a: 'a ，这是非常正确的。 
 
 第二个直接主张'a: 'b 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a: 'b, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 第三个断言是'b: 'a 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a, 'b: 'a>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 这不起作用，因为这不是所需的断言。 
 
 关于不变性呢？ 
 
 我们在这里有两个案例。 首先是使外部引用不可变。 
 
fn use_same_ref_ref<'c>(reference: &'c &'c mut ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 这一个工作。 为什么？ 
 
 那么，考虑我们之前收缩的问题： 
 
 
 
 由于这种情况，一起读写可以防止'b缩小， 
 
 
let ref_ref: &'x mut &'a mut i32 = ...;

{
    // Has lifetime 'b, which is smaller than 'a
    let new_val: i32 = 123;

    // Shrink 'a to 'b
    let new_ref_ref: &'x mut &'b mut i32 = ref_ref;

    *new_ref_ref = &mut new_val;
}

// new_ref_ref is out of scope, so ref_ref is usable again
let ref_ref: &'a mut i32 = *ref_ref;
// Oops, we have an &'a mut i32 pointer to a dropped value!
 
 
 Ergo， 'b不能缩小，它不能从'a ，因此'a == 'b准确地增长。 
 
 
 这只能发生，因为我们可以将内部参考换成一些新的，不够长寿命的参考。 如果我们无法交换参考，这不是问题。 因此缩小内部参考的寿命是可能的。 
 
 而失败的呢？ 
 
 使内部引用不可变无助于： 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a mut &'b ()) {
    use_same_ref_ref(reference);
}
 
 当你认为之前提到的问题从不涉及从内部引用的任何读取时，这是有意义的。 事实上，这里修改了有问题的代码来证明： 
 
let ref_ref: &'x mut &'a i32 = ...;

{
    // Has lifetime 'b, which is smaller than 'a
    let new_val: i32 = 123;

    // Shrink 'a to 'b
    let new_ref_ref: &'x mut &'b i32 = ref_ref;

    *new_ref_ref = &new_val;
}

// new_ref_ref is out of scope, so ref_ref is usable again
let ref_ref: &'a i32 = *ref_ref;
// Oops, we have an &'a i32 pointer to a dropped value!
 
 还有一个问题 
 
 这已经很长了，但回想一下： 
 
 
 
 可以改为执行'a: 'b 
 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a: 'b, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 
 这意味着外部参照的寿命至少与内部参照的寿命一样大。 
 
 
 这并不明显 
 
 
 
  
 为什么&'a mut &'b mut ()不能转换为&'c mut &'c mut () ，或者 
 
  
 这是否比&'a mut &'a mut ()更好。 
 
 
 
 
 我希望回答这些问题。 
 
 
 我们已经回答了第一个问题，但第二个问题呢？ 'a: 'b允许超过'a == 'b吗？ 
 
 考虑一些类型为&'x mut &'y mut ()调用者。 如果'x : 'y ，那么它会自动转换为&'y mut &'y mut () 。 相反，如果'x == 'y ，那么'x : 'y已经存在！ 因此，只有当您希望将包含'x的类型返回给调用者时，差异才是重要的，调用者是唯一能够区分这两者的人。 由于这不是这种情况，所以两者是等价的。 
 
 还有一件事 
 
 如果你写 
 
let mut val = ();
let mut reference = &mut val;
let ref_ref = &mut reference;

use_ref_ref(ref_ref);
 
 其中定义了use_ref_ref 
 
fn use_ref_ref<'a: 'b, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 代码如何能够执行'a: 'b ？ 它看起来像是相反的检验！ 
 
 那么记住这一点 
 
let reference = &mut val;
 
 能够缩短其使用寿命，因为这是此时的外部使用寿命。 因此，即使当指针在该生命周期之外时，它也可以引用比val的实际生命周期更小的生命周期！ 

 
 
Warning: I'm speaking from a level of expertise that I don't really have. Given the length of this post, I'm probably wrong a large number of times.
 
 
 
 
TL;DR: Lifetimes of top-level values are contravariant. Lifetimes of referenced values are invariant.
 
 
Introducing the problem
 
You can simplify your example significantly, by replacing VecRef<'a> with &'a mut T.
 
Further, one should remove main, since it's more complete to talk about the general behaviour of a function than some particular lifetime instantiation.
 
Instead of VecRefRef's constructor, let's use this function:
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}
 
Before we go further, it's important to understand how lifetimes get implicitly cast in Rust. When one assigns a pointer to another explicitly annotated name, lifetime coercion happens. The most obvious thing this allows is shrinking the lifetime of the top-level pointer. As such, this is not a typical move.
 
 
 
Aside: I say "explicitly annotated" because in implicit cases like let x = y or fn f<T>(_: T) {}, reborrowing doesn't seem to happen. It is not clear whether this is intended.
 
 
The full example is then
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
which gives the same error:
 
error[E0623]: lifetime mismatch
 --> src/main.rs:5:26
  |
4 |     fn use_ref_ref<'a, 'b>(reference: &'a mut &'b mut ()) {
  |                                       ------------------
  |                                       |
  |                                       these two types are declared with different lifetimes...
5 |         use_same_ref_ref(reference);
  |                          ^^^^^^^^^ ...but data from `reference` flows into `reference` here
 
A trivial fix
 
One can fix it by doing
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a>(reference: &'a mut &'a mut ()) {
    use_same_ref_ref(reference);
}
 
since the signatures are now logically the same. However, what is not obvious is why
 
let mut val = ();
let mut reference = &mut val;
let ref_ref = &mut reference;

use_ref_ref(ref_ref);
 
is able to produce an &'a mut &'a mut ().
 
A less trivial fix
 
One can instead enforce 'a: 'b
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a: 'b, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
This means that the lifetime of the outer reference is at least as large as the lifetime of the inner one.
 
It's not obvious
 
 
 
why &'a mut &'b mut () is not castable to &'c mut &'c mut (), or
 
 
whether this is better than &'a mut &'a mut ().
 
 
I hope to answer these questions.
 
A non-fix
 
Asserting 'b: 'a does not fix the problem.
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a, 'b: 'a>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
Another, more surprising fix
 
Making the outer reference immutable fixes the problem
 
fn use_same_ref_ref<'c>(reference: &'c &'c mut ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a &'b mut ()) {
    use_same_ref_ref(reference);
}
 
And an even more surprising non-fix!
 
Making the inner reference immutable doesn't help at all!
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a mut &'b ()) {
    use_same_ref_ref(reference);
}
 
BUT WHY??!
 
And the reason is...
 
Hold on, first we cover variance
 
Two very important concepts in computer science are covariance and contravariance. I'm not going to use these names (I'll be very explicit about which way I'm casting things) but those names are still very useful for searching the internet.
 
It's very important to understand the concept of variance before you can understand the behaviour here. If you've taken a university course that covers this, or you can remember it from some other context, you're in a good position. You might still appreciate the help linking the idea to lifetimes, though.
 
The simple case - a normal pointer
 
Consider some stack positions with a pointer:
 
    ║ Name      │ Type                │ Value
 ───╫───────────┼─────────────────────┼───────
  1 ║ val       │ i32                 │ -1
 ───╫───────────┼─────────────────────┼───────
  2 ║ reference │ &'x mut i32         │ 0x1
 
The stack grows downwards, so the reference stack position was created after val, and will be removed before val is.
 
Consider that you do
 
let new_ref = reference;
 
to get
 
    ║ Name      │ Type        │ Value  
 ───╫───────────┼─────────────┼─────── 
  1 ║ val       │ i32         │ -1     
 ───╫───────────┼─────────────┼─────── 
  2 ║ reference │ &'x mut i32 │ 0x1    
 ───╫───────────┼─────────────┼─────── 
  3 ║ new_ref   │ &'y mut i32 │ 0x1    
 
What lifetimes are valid for 'y?
 
Consider the two mutable pointer operations:
 
 
 
Read
 
 
Write
 
 
Read prevents 'y from growing, because a 'x reference only guarantees the object stays alive during the scope of 'x. However, read does not prevent 'y from shrinking since any read when the pointed-to value is alive will result in a value independent of the lifetime 'y.
 
Write prevents 'y from growing also, since one cannot write to an invalidated pointer. However, write does not prevent 'y from shrinking since any write to the pointer copies the value in, which leaves it invariant of the lifetime 'y.
 
The hard case - a pointer pointer
 
Consider some stack positions with a pointer pointer:
 
    ║ Name      │ Type                │ Value  
 ───╫───────────┼─────────────────────┼─────── 
  1 ║ val       │ i32                 │ -1     
 ───╫───────────┼─────────────────────┼─────── 
  2 ║ reference │ &'a mut i32         │ 0x1    
 ───╫───────────┼─────────────────────┼─────── 
  3 ║ ref_ref   │ &'x mut &'a mut i32 │ 0x2    
 
Consider that you do
 
let new_ref_ref = ref_ref;
 
to get
 
    ║ Name        │ Type                │ Value  
 ───╫─────────────┼─────────────────────┼─────── 
  1 ║ val         │ i32                 │ -1     
 ───╫─────────────┼─────────────────────┼─────── 
  2 ║ reference   │ &'a mut i32         │ 0x1    
 ───╫─────────────┼─────────────────────┼─────── 
  3 ║ ref_ref     │ &'x mut &'a mut i32 │ 0x2    
 ───╫─────────────┼─────────────────────┼─────── 
  4 ║ new_ref_ref │ &'y mut &'b mut i32 │ 0x2    
 
Now there are two questions:
 
 
 
What lifetimes are valid for 'y?
 
 
What lifetimes are valid for 'b?
 
 
Let's first consider y with the two mutable pointer operations:
 
 
 
Read
 
 
Write
 
 
Read prevents 'y from growing, because a 'x reference only guarantees the object stays alive during the scope of 'x. However, read does not prevent 'y from shrinking since any read when the pointed-to value is alive will result in a value independent of the lifetime 'y.
 
Write prevents 'y from growing also, since one cannot write to an invalidated pointer. However, write does not prevent 'y from shrinking since any write to the pointer copies the value in, which leaves it invariant of the lifetime 'y.
 
This is the same as before.
 
Now, consider 'b with the two mutable pointer operations
 
Read prevents 'b from growing, since if one was to extract the inner pointer from the outer pointer you would be able to read it after 'a has expired.
 
Write prevents 'b from growing also, since if one was to extract the inner pointer from the outer pointer you would be able to write to it after 'a has expired.
 
Read and write together also prevent 'b from shrinking, because of this scenario:
 
let ref_ref: &'x mut &'a mut i32 = ...;

{
    // Has lifetime 'b, which is smaller than 'a
    let new_val: i32 = 123;

    // Shrink 'a to 'b
    let new_ref_ref: &'x mut &'b mut i32 = ref_ref;

    *new_ref_ref = &mut new_val;
}

// new_ref_ref is out of scope, so ref_ref is usable again
let ref_ref: &'a mut i32 = *ref_ref;
// Oops, we have an &'a mut i32 pointer to a dropped value!
 
Ergo, 'b cannot shrink and it cannot grow from 'a, so 'a == 'b exactly.
 
OK, does this solve our questions?
 
Remember the code?
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
When you call use_same_ref_ref, a cast is attempted
 
&'a mut &'b mut ()  →  &'c mut &'c mut ()
 
Now note that 'b == 'c because of our discussion about variance. Thus we are actually casting
 
&'a mut &'b mut ()  →  &'b mut &'b mut ()
 
The outer &'a can only be shrunk. In order to do this, the compiler needs to know
 
'a: 'b
 
The compiler does not know this, and so fails compilation.
 
What about our other examples?
 
The first was
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a>(reference: &'a mut &'a mut ()) {
    use_same_ref_ref(reference);
}
 
Instead of 'a: 'b, the compiler now needs 'a: 'a, which is trivially true.
 
The second directly asserted 'a: 'b
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a: 'b, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
The third asserted 'b: 'a
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a, 'b: 'a>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
This does not work, because this is not the needed assertion.
 
What about immutability?
 
We had two cases here. The first was to make the outer reference immutable.
 
fn use_same_ref_ref<'c>(reference: &'c &'c mut ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a &'b mut ()) {
    use_same_ref_ref(reference);
}
 
This one worked. Why?
 
Well, consider our problem with shrinking &'b from before:
 
 
 
Read and write together also prevent 'b from shrinking, because of this scenario:
 
 
let ref_ref: &'x mut &'a mut i32 = ...;

{
    // Has lifetime 'b, which is smaller than 'a
    let new_val: i32 = 123;

    // Shrink 'a to 'b
    let new_ref_ref: &'x mut &'b mut i32 = ref_ref;

    *new_ref_ref = &mut new_val;
}

// new_ref_ref is out of scope, so ref_ref is usable again
let ref_ref: &'a mut i32 = *ref_ref;
// Oops, we have an &'a mut i32 pointer to a dropped value!
 
 
Ergo, 'b cannot shrink and it cannot grow from 'a, so 'a == 'b exactly.
 
 
This can only happen because we can swap the inner reference for some new, insufficiently long lived reference. If we are not able to swap the reference, this is not a problem. Thus shrinking the lifetime of the inner reference is possible.
 
And the failing one?
 
Making the inner reference immutable does not help:
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c ()) {}

fn use_ref_ref<'a, 'b>(reference: &'a mut &'b ()) {
    use_same_ref_ref(reference);
}
 
This makes sense when you consider that the problem mentioned before never involves any reads from the inner reference. In fact, here's the problematic code modified to demonstrate that:
 
let ref_ref: &'x mut &'a i32 = ...;

{
    // Has lifetime 'b, which is smaller than 'a
    let new_val: i32 = 123;

    // Shrink 'a to 'b
    let new_ref_ref: &'x mut &'b i32 = ref_ref;

    *new_ref_ref = &new_val;
}

// new_ref_ref is out of scope, so ref_ref is usable again
let ref_ref: &'a i32 = *ref_ref;
// Oops, we have an &'a i32 pointer to a dropped value!
 
There was another question
 
It's been quite long, but think back to:
 
 
 
One can instead enforce 'a: 'b
 
 
fn use_same_ref_ref<'c>(reference: &'c mut &'c mut ()) {}

fn use_ref_ref<'a: 'b, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
 
This means that the lifetime of the outer reference is at least as large as the lifetime of the inner one.
 
 
It's not obvious
 
 
 
  
why &'a mut &'b mut () is not castable to &'c mut &'c mut (), or
 
  
whether this is better than &'a mut &'a mut ().
 
 
 
 
I hope to answer these questions.
 
 
We've answered the first bullet-pointed question, but what about the second? Does 'a: 'b permit more than 'a == 'b?
 
Consider some caller with type &'x mut &'y mut (). If 'x : 'y, then it will be automatically cast to &'y mut &'y mut (). Instead, if 'x == 'y, then 'x : 'y holds already! The difference is thus only important if you wish to return a type containing 'x to the caller, who is the only one able to distinguish the two. Since this is not the case here, the two are equivalent.
 
One more thing
 
If you write
 
let mut val = ();
let mut reference = &mut val;
let ref_ref = &mut reference;

use_ref_ref(ref_ref);
 
where use_ref_ref is defined
 
fn use_ref_ref<'a: 'b, 'b>(reference: &'a mut &'b mut ()) {
    use_same_ref_ref(reference);
}
 
how is the code able to enforce 'a: 'b? It looks on inspection like the opposite is true!
 
Well, remember that
 
let reference = &mut val;
 
is able to shrink its lifetime, since it's the outer lifetime at this point. Thus, it can refer to a lifetime smaller than the real lifetime of val, even when the pointer is outside of that lifetime!