Referece vs borrow

[int0x50]

what is reference vs borrow?

let i = 5;
let j = 6;
let r1 = &i;
let r2 = &j;

as per my understanding, &i and &j is called borrow. But the book says '&i' is a reference.

this code below:

let i = 5;
let j = 6;
let r1 = &mut i;
let r2 = &mut i;

In the above case, compiler throws -> " &mut i; --- first mutable borrow occurs here " and "&mut i; --> second mutable borrow occurs here". so I assume r1 is reference and '&mut i' is 'mutable' borrow.

let i = 5;
let j = 6;
let mut r1 = &i;
let mut r2 = &i;

now by this, I have two mutable reference. this goes completely against 'At any given time, you can have either one mutable reference ... '

I see the compiler does 'borrow checker' and not 'reference checker'. Why it's wrtten like that in the book?

isn't the left side is reference and right side is borrow?

[paramagnetic]

@int0x50

what is reference vs borrow?

They are the same. At most, you can take the verb borrow to denote the act of taking a reference, but this difference is immaterial and purely linguistic.

@int0x50

now by this, I have two mutable reference.

No you don't. &i results in a shared (immutable) reference.

The exclusiveness of mutability doesn't concern the mutability of the reference itself; the mutability of values and places in Rust is basically just a lint — it could be completely eliminated while keeping the exact same memory model.

The exclusiveness of mutability is about the pointed place of a &mut reference, ie., it only matters when the place/value to be mutated is behind indirection.

The let mut r1 = &i; means that the variable r1 (ie., the reference itself) is mutable, so you can re-assign it to point to another place. It does NOT allow you to mutate i.

(Draw diagrams of the pointers and pointed values for yourself, and you'll find this trivial.)

[FZs]

@paramagnetic explained it well, but a piece of code is worth a thousand words, so:

let i = 5;

let mut r1 = &i;

*r1 = 7; 
// this would change i, but it is not allowed

let i = 5;
let j = 6;

let mut r1 = &i;

r1 = &j; 

// does not change i, only r1 so it works

println!("{i} {j} {r1}"); // 5 6 6

let mut i = 5;

let r1 = &mut i;

*r1 = 7;
//changes i, allowed

println!("{i} {r1}"); // 7 7

[int0x50]

@FZs

going by your same example

let i = 5;
let mut r1 = &i;
*r1 = 7;

// this would change i, but it is not allowed

yes, because r1 is a mutable reference, but the borrow is immutable (&i). so *r1 is an illegal operation.

let i = 5;
let j = 6;
let mut r1 = &i;
r1 = &j;

// does not change i, only r1 so it works

yes, because r1 is a mutable reference, first time it can borrow from i and second time from j.

let i = 5;
let r1 = &mut i;
*r1 = 7;

//changes i, allowed

yes, because r1 is a immutable reference, but has performed mutable borrow. so it can change i.

[int0x50]

in a code like this

let i = 5;
let r1 = &i;

What do we call 'r1' as and '&i' as ?

[jameseb7]

@int0x50

let i = 5;
let mut r1 = &i;
*r1 = 7;

// this would change i, but it is not allowed

yes, because r1 is a mutable reference, but the borrow is immutable (&i). so *r1 is an illegal operation.

No, here r1 is an immutable (or shared) reference stored in a mutable binding.

@int0x50

let i = 5;
let r1 = &mut i;
*r1 = 7;

And here r1 is a mutable reference stored in an immutable binding.

[quinedot]

@paramagnetic

the mutability of values and places in Rust is basically just a lint — it could be completely eliminated while keeping the exact same memory model.

The exclusiveness of mutability is about the pointed place of a &mut reference, ie., it only matters when the place/value to be mutated is behind indirection.

Saying the same thing with different words in case it helps:

• let mut variable = ... versus let variable = ... -- a mut or non-mut binding -- is the lint-like distinction. The mut does not change the type of the variable or anything like that. Given a program that compiles, making every binding a mut binding changes nothing aside from some lint-like warnings. A non-mut binding prevents overwriting or taking a &mut to the variable. It doesn't prevent mutation via indirection,^[1] interior mutability,^[2] or moving to a new mut binding^[3] (or even moving to a new temporary place).

• &SomeType and &mut SomeType, in contrast, are different types with significantly different semantics.^[4]

---

Rust doesn't actually have any surface syntax for shallow immutability so far,^[5] and also has no way to enforce deep immutability at all.^[6] Despite the mut syntax and what most learning material says, the real distinction in Rust is exclusive-vs-shared, not mutable-vs-immutable.

---

As far as my personal vocabulary goes, references are those & and &mut things, where as "borrows" is a more general concept. For example, an Iter<'_, T> can be a borrow of some slice, but doesn't actually contain any references (that you can observe outside of std, and also in the current implementation).

And even when all the types involved are references, a &[T] can be a borrow of a Vec<T> for example, even though the former is not a reference to a Vec<T>. That is, in my way of thinking, lifetimes being tied together via constraints like

// Desugared signature of `<Vec<T> as Deref>::deref`
fn deref<'a>(self: &'a Vec<T>) -> &'a [T]

is interpreted as the &[T] being or holding a borrow/reborrow of the &Vec<T>.

So as far as I'm concerned: references are borrows; not all borrows are references.

---

1. in its simplest form: let x: &mut _ = ... ↩︎

2. e.g. Mutex<_>, RefCell<_>, atomics ↩︎

3. let x = ...; let mut x = x; ↩︎

4. The link also introduces reborrowing in brief, which underpins a lot of "multiple &muts to the same place" confusion ↩︎

5. but may gain a trait for it ↩︎

6. which is undecidable without breaking changes, so it won't gain this ability ↩︎

[richr]

This code sample that you have:

let i = 5;
let r1 = &mut i;
*r1 = 7;

would need to be changed to use let mut i = 5, otherwise you can't take a mutable reference to it on the next line.

For your question about the following code sample:

let i = 5;
let r1 = &i;

• &i is a shared (aka immutable) reference to i - the & operator is used to create such a reference; this could also be referred to as "borrowing i")
• r1 is a variable (of type &i32) that holds the reference

[int0x50]

r1 is a variable (of type &i32) that holds the reference -> the moment you have 'of type &i32', isn't a reference then? so r1 cannot be a 'variable' but a reference?

the & operator is used to create such a reference -> you have said this.

[int0x50]

    let i = 4;
    let r1 = &i;
    println!("value is: {}", r1);

    let r1 = 4;
    println!("value is: {}", r1);

in the above code, if we go by like 'r1' is a variable on two occasions. How does Rust knows, the first time it's reference and second time it directly holds the value?

[quinedot]

@int0x50

r1 cannot be a 'variable' but a reference?

A variable can be a reference (a variable's type can be a reference type and its value be a reference value) in the same way that a variable can be a String (a variable's type can be String and its value be a String value).

References have some special language-level abilities, like reborrowing, but otherwise they are still types.^[1] Rust references are roughly speaking pointers with stricter invariants and borrow checking. They're not magical aliases (in contrast with some other programming languages).

@int0x50

How does Rust knows, the first time it's reference and second time it directly holds the value?

That's shadowing. They're two different variables. Rust knows they're different the same way it knows that these two variables are an i32 and a String. It's nothing reference specific.

let x = 0;
let x = String::new();

---

1. Technically, type constructors. ↩︎

[richr]

I’m just on mobile so need to be brief but here we have to consider both types and values - you can have a variable that is of a reference type, that holds a reference value

(In the same way that i32 is a type, and 5 is a value)

[FZs]

@int0x50

in the above code, if we go by like 'r1' is a variable on two occasions. How does Rust knows, the first time it's reference and second time it directly holds the value?

Those are two different variables (bindings), that happen to have the same name (but are of no relation to one another).

It's the type that's different. At first, it is of type &i32, which is a reference. But I wouldn't say the variable is a reference, I'd say it stores or holds a reference.
The second time the type is i32. Still, the variable isn't a number, it stores a number.

[paramagnetic]

@int0x50

in the above code, if we go by like 'r1' is a variable on two occasions. How does Rust knows, the first time it's reference and second time it directly holds the value?

Because the language is statically typed.

Note that there are two distinct variables named r1. They are not the same variable. let isn't an assignment, it's a declaration that creates a fresh variable.

[int0x50]

    let a = 44;
    let r1 = &a;
    let r2 = &a;

// here r1 and r2 are called immutable reference ?

    let a = 44;
    let mut r1 = &a;
    let mut r2 = &a;

// here r1 and r2 are called what ?

[Cerber-Ursi]

@int0x50

here r1 and r2 are called immutable reference ?

They are called immutable bindings, or immutable variables, holding immutable references.

@int0x50

// here r1 and r2 are called what ?

They are called mutable bindings, or mutable variables, holding the same immutable references.

[quinedot]

let ns = &a;
let nx = &mut b;
let mut ms = &c;
let mut mx = &mut d;

nx and mx are exclusive references, or mutable references. ns and nx are shared references. Some do call these "immutable references", but that can be misleading as it is possible to mutate through a shared reference in some cases. Here's an article on the topic.

I would call ms and mx mut bindings, and ns and nx non-mut bindings. The distinction doesn't come up in conversation much; the compiler will tell you when you need to add or remove mut. And as mentioned, adding mut to every binding doesn't change the semantics of a compiling program.