"Copying" mutable references

jruh7 · December 7, 2022, 4:50pm

It's basically about two things: having a non-mutable reference and a mutable reference
at the same time; what happens when a mutable reference is 'copied' (e.g. when passed to
a function).

In the following, I describe my questions and some thoughts that I have about them; I
would be really happy if someone could comment on them and correct me.

Having a non-mutable reference and a mutable reference at the same time

The following doesn't compile because of the standard rules

let mut s = String::from("hello");
let mr = &mut s;
let r = &s;
*mr = String::from("world");

However, we can do (ignore for now that we are kind of copying a &mut T here, although
&mut T is not Copy (see second question))

let mut s = String::from("hello");
let mr = &mut s;
let cr: &String = mr;
*mr = String::from("world");

but it doesn't work if we use cr after we made use of the mutability in mr

let mut s = String::from("hello");
let mr = &mut s;
let cr: &String = mr;
*mr = String::from("world");
println!("{}", cr);

So what is going on here? cr is kinda copied from mr while r directly takes the
reference to s. Where is the difference?

Let's start at the beginning:

Ignoring the borrow checker for a moment, there is no reason why the following shouldn't
be possible code, because r effectively only lives in a time area where mr is not used
as a mutable reference.

let mut s = String::from("hello");
let mr = &mut s;
let r = &s;
*mr = String::from("world");

Even something like the following should be possible

let mut s = String::from("hello");
let mr = &mut s;
let r = &s;
let _a = r.clone();
let _a = mr.clone();
let _a = r.clone();
*mr = String::from("world");

It should only be impossible if we try to use r after we made use of the mutability in
mr, i.e.,

let mut s = String::from("hello");
let mr = &mut s;
let r = &s;
*mr = String::from("world");
println!("{}", r);

shouldn't work. Let's check whether this is the case when we have cr instead of r:

let mut s = String::from("hello");
let mr = &mut s;
let cr: &String = mr;
let _a = cr.clone();
let _a = mr.clone();
let _a = cr.clone();
*mr = String::from("world");

It does compile!

So we see that with cr we have some kind of extended borrowing rules, which are that as
long as cr only lives in a time area where mr's mutability is not used, it is ok. Let's
see what happens if we define cr as &mut String:

let mut s = String::from("hello");
let mr = &mut s;
let cr: &mut String = mr;
let _a = cr.clone();
let _a = mr.clone();
// let _a = cr.clone(); // not allowed
*mr = String::from("world");

Here we cannot use mr in between. That makes sense, but the borrowing rules are still
extended.

Why is this the case with cr and not with r? To answer that, let's first think about
what we have gained by defining cr (or r) in the examples that compile (should be
possible). Effectively nothing! In every position where we used cr, we could have used
mr. In the case of r, it is clear that we can never do anything useful with r, so
instead of waiting until we want to do something 'useful' with r after the mutability
use in mr, which is not allowed, we are not allowed to define r in the first place. But
why does this not happen with cr? The answer is that cr has its use cases, probably the
most important one being function calls with references as parameters:

fn bar(cr: &String) {}
fn bar_mut(cr: &mut String) {}
let mut s = String::from("hello");
let mr = &mut s;
bar(mr);
bar_mut(mr);
// bar(&s); // error
// bar_mut(&mut s); // error
*mr = String::from("world");

We couldn't call bar(_mut) with mr if it wouldn't be possible to define a reference
(cr) during the lifetime of mr. So we see that it is necessary to have these extended
borrowing rules for cr. The following shows another example where this extension is
necessary

struct Wrapper<'t> {
    some_string: &'t mut String,
}
let mut s = String::from("hello");
let cr: &String; // ok
// let i; // not allowed
// let mut i: &String = &String::from("world"); // ok
// let mut i = &String::from("world"); // ok
{
    let w = Wrapper { some_string: &mut s };
    cr = w.some_string;
    let _a = w.some_string.clone();
}
println!("{}", cr);

I think, what the examples above have in common is that a variable declared as a
&String is allocated by a variable that is a &mut String. This brings me to my
next question.

What happens when a mutable reference is 'copied'

What happens when we pass mutable references to functions or define cr as in the
examples in the first question, i.e., what happens in

fn baz(cr: &String) {}
fn baz_mut(cr: &mut String) {}
let mut s = String::from("hello");
let mr = &mut s;
let cr: &String = mr;
bar(mr);
bar_mut(mr);
*mr = String::from("world");

with mr? It cannot be copied (since &mut T is not Copy) and it cannot be moved (because
it used later on). Is this some 'builtin magic', and if so is this how the compiler
differentiates between cr and r in the examples in the first question?

alice · December 7, 2022, 5:03pm

The operation you're looking at is called a reborrow. Given a mutable reference, you can create a sub-reference (mutable or immutable), and for the duration in which the sub-reference is live, access to the original mutable reference is restricted. If the sub-reference is mutable, no access to the original reference is allowed. If the sub-reference is immutable, some immutable uses of the original reference are allowed, but nothing else.

steffahn · December 7, 2022, 5:13pm

Looks like reborrowing is still poorly documented...

github.com/rust-lang/reference

better documentation of reborrowing

opened 08:57PM - 04 Apr 20 UTC

soulwa

### tl;dr: Rust documentation is unclear on reborrowing, should explain details …in the Reference As it stands, there is only one mention of "reborrowing" in the Reference, [in this section on raw pointers](https://doc.rust-lang.org/stable/reference/types/pointer.html#raw-pointers-const-and-mut). This only refers to reborrowing pointers, and not references, which is important in understanding how Rust handles mutable references (often implicitly reborrowing them instead of moving them). There is also [some documentation on implicit borrowing](https://doc.rust-lang.org/stable/reference/expressions.html?highlight=implicit,borrows#implicit-borrows), but again, this is sparse and does not cover reborrowing in the context of mutable references. A key example of the implicit borrowing which confused me is the following: ```rust fn main() { let mut x = vec![1, 2, 3]; let y = &mut x; let z: &mut Vec<i32> = y; z.push(4); y.push(5); } ``` This code compiles fine, and `x`, as expected, becomes `[1, 2, 3, 4, 5]`. Initially, this code was unclear to me, but I was able to understand how it worked learning about both reborrowing and non lexical lifetimes. However, along the way I became familiar with how little documentation there is on the former. Questions have come up on the topic frequently, like [this Reddit post](https://www.reddit.com/r/rust/comments/46qwjv/why_can_i_use_an_mut_reference_twice/) from 2016, [this post](https://users.rust-lang.org/t/mut-t-seems-to-behave-like-a-copy-type/16578) from 2018 on the Rust forums, more Reddit posts from [2018](https://www.reddit.com/r/rust/comments/891fnj/copying_mut_t/) and [2019](https://www.reddit.com/r/rust/comments/b060ew/why_i_can_move_a_mut_t_twice_in_some_cases/), and in [this forum post](https://users.rust-lang.org/t/questions-about-mut-t-and-move-semantics-mut-t-is-move-only/37484/13) from January, which I found extremely helpful. A few of the discussions in these posts reference sources to reborrowing, but the only official documentation which was available is [an earlier version of the Rustonomicon](https://doc.rust-lang.org/1.12.0/nomicon/references.html#liveness). There are some instances of the author of The Rust Programming Language, such as [here](https://www.reddit.com/r/rust/comments/464jge/lifetime_issues_turning_tail_recursion_into_a_loop/d03k1b3/), [here](https://www.reddit.com/r/rust/comments/46qwjv/why_can_i_use_an_mut_reference_twice/d0824w8/), and in https://github.com/rust-lang/rust/issues/25899, mentioning adding reborrowing to the new book, but it seems that has been abandoned since: see https://github.com/rust-lang/book/issues/2144. This concept is counter-intuitive to beginners, as it seems to violate the idea that there can only be one mutable reference to an object in a given scope. It also raises frequent forum questions, which become an effective way to get answers, but only due to the lack of documentation. Because of this, I think that some proper documentation on reborrowing is necessary. It would explain some of the quirks of this system, as choosing whether or not to reborrow is a decision made by the compiler, and can lead to some strange compilation errors without understanding this concept. For example, ```rust let mut x = vec![1, 2, 3]; let y = &mut x; let z = y; ``` will move y into z, but substituting the last line for ```rust let z: &mut _ = y; ``` will reborrow y, since the compiler has to guarantee that `z` is `&mut T`. `y` can be freely used after the second case, but not at all after the first case. Rust has also made some progress with reborrowing, as issues like [reborrowing in match arms](https://www.reddit.com/r/rust/comments/464jge/lifetime_issues_turning_tail_recursion_into_a_loop/) which failed to compile in the past now work fine, without the need to force a move. The compiler can infer when it is necessary to move a &mut instead of reborrow it, but the logic behind this decision should be made clear to the programmer so that there is a better understanding of the final product. It seems like there was some effort to document this topic (through non-lexical lifetimes) in #290. This documentation is unfinished, potentially due to the in-progress nature of non-lexical lifetimes, but the feature is stable, which means it could accompany a discussion of reborrowing. I think reborrowing is an important enough topic to get covered in some official documentation, and if not the book, then the reference should expand upon this technique.

...but one at least this Github issue is nice enough to collect a handful of links to prior discussions and explanations in forums. So feel free to take a look ^^

steffahn · December 7, 2022, 5:18pm

I'm in mobile and about to go to bed, but to explain just one detail here...

let cr: &String = mr;

with mr: &mut String does effectively “desugar” to something like

let cr: &String = &*mr;

I. e. the target of mr is being (immutably) borrowed, and while this borrow is active, mr (or its target) can no longer be mutated.

(More precisely, in this case what I called “desugar”ing is the implementation of the implicitly added coercion &mut String to &String. But in other cases, like with the explicit &mut String type signature in a later example, the compiler likes to insert a (that time mutable) re-borrow even without any coercions being necessary in the first place... in a sense, &mut T is a bit magical in this regard, but the magic is only that an expression foo that looks like it loves a mutable reference can sometimes implicitly become effectively &mut *foo.)

tczajka · December 7, 2022, 6:04pm

My understanding is this:

let mut s = String::from("hello");
let mr = &mut s;
let cr: &mut String = mr;

translates into:

let mut s = String::from("hello");
let mr: &'a mut String = &mut s;
let cr: &'b mut String = mr;

Note that the two types are different because there are different lifetimes. Therefore this is not just a move, but a type coercion. The type coercion inserts a reborrow.

But if you explicitly write the code with the same lifetime, then it doesn't work (from reading the error message I think there is still technically a reborrow inserted, but that doesn't really matter):

fn foo<'a>(mr: &'a mut String) {
    let cr: &'a mut String = mr;
    println!("{cr}");
    println!("{mr}");
}

system · March 7, 2023, 6:05pm

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.

Topic		Replies	Views
Need some clarification on the behavior of mutable references help	5	321	May 22, 2024
Understanding References with 3 simple programs help	4	179	June 3, 2024
How to Understand Referenced References? help	8	397	January 23, 2024
Borrowing from a mutable reference help	6	1178	August 25, 2023
Mutable reference is not Copy type help	6	2346	January 12, 2023

"Copying" mutable references

Having a non-mutable reference and a mutable reference at the same time

What happens when a mutable reference is 'copied'

Related topics