One owner, many immutable references?

How can a value with many immutable references only have one owner? There is something here I am missing about what the borrow checker is enforcing.

Broadly speaking:

  • The shared references are the result of borrowing from the single owner.
  • Ownership is not a kind of reference.

Shared ownership is accomplished through types like Rc and Arc, which, like references, are kinds of pointers, but unlike references, do not involve borrowing at all.

8 Likes

Recommend reading:

https://limpet.net/mbrubeck/2019/02/07/rust-a-unique-perspective.html

1 Like

Only the owner can mutate the thing, assuming the thing is mut and it has not been loaned out with a reference.

Only the owner can destroy/drop/deallocate the thing.

As far as I can tell with shared reference via Rc or whatever the Rc is the owner (?). When the Rc sees no more references (reference count goes to zero) the Rc can destroy/drop/deallocate/ the thing.

Then I'm confused about what the borrow checker is enforcing when it comes to the "1 mutable OR many immutable".

And if ownership isn't some kind of pointer to the current scope, what is it?

And I thought reference counting was outside the scope of the borrow checker?

The borrow checker only cares about borrows, not ownership. Creating a reference is borrowing.

Ownership is a pattern/contract — there is no single language feature that implements all ownership. Ownership is “I am responsible for ensuring this value is dropped and the memory it occupied is deallocated after it is not in use, and no sooner, and not more than once”, and what “I” is can be lots of things. A regular let variable implements ownership; Box implements ownership; Rc implements ownership; and all of these things do that using different code and different strategies.

Box and Rc are owner types that consist of pointers to heap allocations. References are/have pointers but are not owners. Pointers can exist without being owners, and owners can exist without being pointers.

It is. The word “reference” in “reference counting” is a term that predates Rust and is more general than the things Rust calls “references”. Rc<T> and &T do have in common that you can have many of them which point to the same T, but they work by completely different means.

You can borrow from a Rc<T> to get an &T, though.

I like the book metaphor to get an intuition started for ownership and mutability XOR shared references.

I have a book. I own this book. I can write in the margins and rip out pages because it is mine.

I show my book to a friend. They don't own it. If they write in it and rip out pages I will be upset.

Many people can come and look at the book all at the same time, including me. We could sit and look at the book together, sharing it.

If I write on the book or rip out a page while we are all looking at it, others might be annoyed, as they were looking at the page I just ripped out or wrote all over.

Once everyone is done looking at the book, I can put the book back on the shelf, and nobody will be annoyed.

(I start trying to fit mutable references into this analogy now, it's a little awkward)

I might lend it to a friend, and say here, this is yours for now but I want it back. You can even write in it and rip out pages if you need to. Nobody else will be looking at it or writing in it or ripping out pages until you give it back to me. Don't let anyone else look at the book while you're writing in it... (Admittedly this is a weak part of the metaphor)

Or I might gift it to a friend. I could ask them for permission to look at it from time to time. It's up to them now because they own it. They might be writing in it, they might have lent it to a friend or they might have put it back on the shelf.

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.