Why does creating a mutable reference to a derefer

Question

I understand you're not allowed to create two mutable references to an object at once in Rust. I don't entirely understand why the following code works:

fn main() {
    let mut string = String::from("test");
    let mutable_reference: &mut String = &mut string;
    mutable_reference.push_str(" test");
    // as I understand it, this creates a new mutable reference (2nd?)
    test(&mut *mutable_reference);

    println!("{}", mutable_reference);
}

fn test(s: &mut String) {
    s.push_str(" test");
}

Answer 1

Is there more than one mutable pointer somewhere in memory referring to the same location? Yes.

Is there more than one mutable pointer in the code to the same location which is usable? No.

Re-borrowing a mutable pointer locks out the one you're re-borrowing from.

Answer 2

The rule

There shall only be one usable mutable reference to a particular value at any point in time.

This is NOT a spatial exclusion (there CAN be multiple references to the same piece) but a temporal exclusion.

The mechanism

In order to enforce this, &mut T is NOT Copy; therefore calling:

test(mutable_reference);

should move the reference into test.

Actually doing this would make it unusable later on and not be very ergonomic, so the Rust compiler inserts an automatic reborrowing, much like you did yourself:

test(&mut *mutable_reference);

You can force the move if you wanted to:

test({ let x = mutable_reference; x });

The effect

Re-borrowing is, in essence, just borrowing:

• mutable_reference is borrowed for as long as the unnamed temporary mutable reference exists (or anything that borrows from it),
• the unnamed temporary mutable reference is moved into test,
• at the of expression, the unnamed temporary mutable reference is destroyed, and therefore the borrow of mutable_reference ends.

Answer 3

I analyzed the differences in MIR between test(mutable_reference) and test(&mut *mutable_reference). It appears that the latter only introduces an additional level of indirection:

When you are using an extra dereference in the function call, it doesn't create a mutable reference that holds; in other words, it doesn't cause any actual difference outside the function call.