如何在 Rust 中拥有多个可以访问其值的共享引用？

Question

I'm new to Rust and already have read "the book" but I'm trying to understand the inners of references in the language.

As far as I know a reference is a type of pointer that takes you to some value in memory when dereferenced.

let x = 5
let y = &x

In this example y is a pointer to the memory address of x and so the type and value of y is not equal to the type and value of x .

assert_eq!(y, x)
// fails to compile as assert_eq! has no implementation for `&{integer} == {integer}`

1. Then a reference is not the same as the value it references to.

But if I dereference the y by using the * operator I now do get the value it referenced and so the following code compiles.

assert_eq!(*y, x)

2. To access the value the reference points to, dereferencing is needed; but dereferencing implies moving the ownership of the referenced value to the new variable.

let x = Point {x:1, y:2};
let y = &x;
let z = *y;
// fails to compile as move occurs because `*y` has type `Point`, which does not implement the `Copy` trait

3. By implementing the Copy trait for the type ( Point in this case) the problem can be solved by letting Rust create a copy of the value and move the ownership of the copied value to the new variable.

The final question is, how can Rust access a value of a type that does not implement the Copy or Clone traits and is behind a reference without having the dereference ( * ) function take ownership of the value, thus making other shared references to the original value invalid?

Eg (works just fine)

let x = Point {x:1, y:2};
let y = &x;
let z = &x;

fn print_point(a: &Point){
    println!("{a:#?}")
}

println!("Printing y");
print_point(y);
    
println!("Printing x");
println!("{x:#?}");

println!("Printing z");
print_point(z);

( Playground )

Answer 1

The ownership semantics of Rust are more complex than simply giving ownership or denying access.

First, there is a little background to be explained about pointers in Rust . A pointer is just an integer that indicates an index of the memory. It's usually beginner-friendly to think of it as an arrow pointing to a location in memory. An arrow is not what it points to, but it's easy to get the value pointed by an arrow given the arrow (just look where it points to).

All pointer-like in Rust are either just that arrow, or that arrow a little more information about that value (so that you don't have to read the value to know that information). By pointer-like I mean anything that behaves like a pointer, that is, can be dereferenced (to keep it simple).

For example, the borrow of x ( &x ) is not exactly a pointer ("actual" pointers in Rust are used less often than borrows and would be either *mut x or *const x ), it's a pointer-like. This pointer-like is just an integer: once your program is compilated, you couldn't tell the difference between a borrow and a pointer. However, contrary to "just a number", a borrow holds some additional constraints. For instance, it's never a null-pointer (that is, a pointer that points to the very-first position of the memory; by convention — and for technical reasons concerning the allocator — this area is never allocated, that is, this pointer is always invalid ). In fact, more generally, a borrow should never be invalid : it should always be safe to dereference it (NB. safe doesn't mean legal , Rust could prevent you from dereferencing it, as in the example you posted), in the sense that the value that it points to always "makes sense". This is still not the strongest guarantee provided by a borrow, which is that, for as long as someone holds the borrow (that is, for as long as someone could use it), no one is going to modify the value it points to. This is not something you have to be careful about: Rust will prevent you from writing code that could break this.

Similarly, a mutable borrow ( &mut x ) is also a pointer-like that is "just an integer", but has different constraints. A mutable borrow (also called "exclusive borrow"), besides always being valid, ensures that, as long as one person is holding it, no one else can access the value it points to, either to modify it or just to write it. This is to prevent data races, because the one that hold the exclusive borrow can modify the value, even though they don't own the value.

These are definitively the most common pointer-like used in Rust (they're everywhere), and could be seen as the read-only but multi-access version of a pointer, or the read-and-write but single-access version of a pointer.

---

Having understood that, it's easier to understand Rust's logic. If I have y = &x , I am allowed to read the value x , but I can't "take" it (that is, take its ownership): I can't even write to it (but I should be able to if I owned it)! Note that even if I have an exclusive borrow, I couldn't take the ownership of x , but I could "swap" it: take its ownership in exchange for the ownership of a variable I owned (or create an owned variable for the occasion). For this reason, if you write let z = *y , you are taking the ownership of x so Rust complains. But note that this is due to the binding, not the the dereferencing of y . To prove it, compare it with the following ( String is not Copy ):

let a = String::new();
let b = &a;
let c = &a;
assert_eq(*b, *c);

playground

Here, I dereference the borrow to a non- Copy value, but it's clear that I am not violating the borrow contract (to compare equality, I just need to read the value).

Furthermore, in general, if I have a borrow of a struct , I can obtain borrows of the its fields.

---

Incidentally, note that String is a pointer-like too! It's not "just a number" (meaning it carries more information than just being an arrow). These pointer-like that are more than "just a number" are called fat pointers. String is a fat pointer to an owned str , that is, String is a kind of pointer that also ensure that whomever owns it also owns the pointed value, which is why String is not Copy (otherwise, the pointed value could be owned by multiple parties).

Answer 2

To access the value the reference points to, dereferencing is needed; but dereferencing implies moving the ownership of the referenced value to the new variable.

Dereferencing does not imply moving. The motivating example presented let z = *y simply dereferences y and then moves/copies the value to z . Yet if you do not assign the value to a new variable there is no new variable and therfore no transfer of ownership.

This might help building an intuition:

You make the (correct) case that a reference is a different thing from the object it points to. However implying that you would need to assign it after dereferencing in order to do anything with it (wrong). Most of the time you are fine working directly on the members, which may be copyable. If not maybe the members of the members are. In the end it is likely to all just to boil down to bytes.