Copying references and their lifetime

[MMK]

N1:

Why mut references doesn't implement copy, because it can be easily reborrowed.

doesn't compile:

    let mut a=100;
    let b=&mut a;
    let c=b;
    b;

compile:

    let mut a=100;
    let b=&mut a;
    let c=&mut *b;
    b;

N2:

Why lifetime of T is equal to &mut T

doesn't compile:

struct ST<'a>{
    inner:&'a mut i32
}

impl<'a> ST<'a>{
    fn get(&self)->&'a i32{
        & *self.inner
    }
}

(lifetime of inner is equal to &self)

compile:

struct ST<'a>{
    inner:&'a i32
}

impl<'a> ST<'a>{
    fn get(&self)->&'a i32{
        & *self.inner
    }
}

(return longer lifetime)

N3:
How copying differs from reborrowing

[alice]

The difference is that copying gives you another reference with the same lifetime, whereas reborrowing gives you a reference with a "sub-lifetime".

One way to understand why this happens is that mutable references must be unique. There can only be one mutable reference at the time to a value. If you could copy them, then you would violate that rule. However, reborrowing avoids that in the following way:

• For the duration from the creation of the sub-reference, until the last use of the sub-reference, the parent reference is mutably borrowed. This means that the parent reference is effectively disabled and can't be used for that duration.

So even though you end up with two mutable references, you can only use one of them at the time, and this is enough for the rule that mutable references must be unique.

An interesting side-note is that this is implemented using borrowing. In the compiler's eye, the sub-reference borrows from the parent reference as opposed to borrowing from the actual owner of the variable. Since variables can't be accessed while they are mutably borrowed, this gives the desired effect of disabling the parent reference.

[SkiFire13]

A reborrow is different from a copy in that a reborrowed mutable reference can not be used while the reborrow exists, while a copy is completly separated from the value you're copying and you can use both at the same time.

In the N2 example with the mutable reference you can only reborrow, getting a reference with the lifetime of &self (if the function took a &'b self you could get a &'b i32), which is not 'a (that'a the lifetime of whatever the ST contains, but not of the reference to the ST). 'a and 'b are however related in that 'a is guaranteed to be longer than 'b, but this is useless in your example. The example with the immutable reference instead works because the reference can be copied.

Also note that the example with the mutable reference must not compile because if it did you would be able to access the inner field while you hold the return value of get, which breaks the borrowing rules because you would have access to both an immutable and a mutable reference to the same data.

[H2CO3]

The whole point of Rust's borrowing model is to prevent shared mutability.

Copying means making an independent duplicate. If you could make a copy of a mutable reference, then the lifetime of the copy wouldn't be tied to the lifetime of the original, and you would end up with two, independently usable mutable references, which is unsound.

If you reborrow, the originating reference is rendered unusable by the compiler until the reborrow ends. That wouldn't be the case with a copy.

See e.g. this answer of mine from a few hours ago, for a demonstration in a similar but not completely identical situation. The unsound code in that answer effectively makes an independent copy instead of reborrowing, which is incorrect.

[MMK]

Indeed, this code and this one are different things

doesn't compile:

   let mut a=100;
    let b=&mut a;
    let c=&mut a;
    *c=100;
    
    b;

compiles:

let mut a=100;
    let b=&mut a;
    let c=&mut *b;
    *c=100;
    
    b;

compiles:

struct ST<'a>{
    inner:&'a mut i32
}

impl<'a> ST<'a>{
    fn get(self)->&'a mut i32{
        self.inner
    }
}