Understanding usage of Rc> in Rust

Question

I'm looking at some code that uses

Rc<RefCell<SomeStruct>>

So I went out to read about the differences between Rc and RefCell:

Here is a recap of the reasons to choose Box, Rc, or RefCell:

Rc enables multiple owners of the same data; Box and RefCell have single owners.

Box allows immutable or mutable borrows checked at compile time; Rc allows only immutable borrows checked at compile time;

RefCell allows immutable or mutable borrows checked at runtime. Because RefCell allows mutable borrows checked at runtime, you can mutate the value inside the RefCell even when the RefCell is immutable.

So, Rc makes sure that SomeStruct is accessible by many people at the same time. But how do I access? I only see the get_mut method, which returns a mutable reference. But the text explained that "Rc allows only immutable borrows".

If it's possible to access Rc's object in mut and not mut way, why a RefCell is needed?

Answer 1

So, Rc makes sure that SomeStruct is accessible by many people at the same time. But how do I access?

By dereferencing. If you have a variable x of type Rc<...>, you can access the inner value using *x. In many cases this happens implicitly; for example you can call methods on x simply with x.method(...).

I only see the get_mut method, which returns a mutable reference. But the text explained that "Rc allows only immutable borrows".

The get_mut() method is probably more recent than the explanation stating that Rc only allows immutable borrows. Moreover, it only returns a mutable borrow if there currently is only a single owner of the inner value, i.e. if you currently wouldn't need Rc in the first place. As soon as there are multiple owners, get_mut() will return None.

If it's possible to access Rc's object in mut and not mut way, why a RefCell is needed?

RefCell will allow you to get mutable access even when multiple owners exist, and even if you only hold a shared reference to the RefCell. It will dynamically check at runtime that only a single mutable reference exists at any given time, and it will panic if you request a second, concurrent one (or return and error for the try_borrow methods, respecitvely). This functionality is not offered by Rc.

So in summary, Rc gives you shared ownership. The innervalue has multiple owners, and reference counting makes sure the data stays alive as long as at least one owner still holds onto it. This is useful if your data doesn't have a clear single owner. RefCell gives you interior mutability, i.e. you can borrow the inner value dynamically at runtime, and modify it even with a shared reference. The combination Rc<RefCell<...>> gives you the combination of both – a value with multiple owners that can be borrowed mutably by any one of the owners.

For further details, you can read the relevant chapters of the Rust book:

• Rc<T>, the Reference Counted Smart Pointer
• RefCell<T> and the Interior Mutability Pattern

Answer 2

If it's possible to access Rc's object in mut and not mut way, why a RefCell is needed?

• Rc pointer allows you to have shared ownership. since ownership is shared, the value owned by Rc pointer is immutable

• Refcell smart pointer represents single ownership over the data it holds, much like Box smart pointer. the difference is that box smart pointer enforces the borrowing rules at compile time, whereas refcell enforces the borrowing rules at run time.

If you combine them together, you can create a smart pointer which can have multiple owners, and some of the owners would be able to modify the value some cannot. A perfect use case is to create a doubly linked list in rust.

struct LinkedList<T>{
    head:Pointer<T>,
    tail:Pointer<T>
}

struct Node<T>{
    element:T,
    next:Pointer<T>,
    prev:Pointer<T>,
}
// we need multiple owners who can mutate the data
// it is Option because "end.next" would be None
type Pointer<T>=Option<Rc<RefCell<Node<T>>>>;

In the image "front" and "end" nodes will both point to the "middle" node and they can both mutate it. Imagine you need to insert a new node after "front", you will need to mutate "front.next". So in doubly linked you need multiple ownership and mutability power at the same time.