book RefCell<Rc<?>> vs Rc<RefCell<?>> in Chapter 15.6

Chapter 15.6 of the Rust Book 2018 edition includes the following code:

struct Node {
    value: i32,
    parent: RefCell<Weak<Node>>,
    children: RefCell<Vec<Rc<Node>>>,
}

This has a Rc inside a RefCell, but the pattern in other places and the previous section is put the RefCell inside the Rc. It would be nice if the book either used the more common idiom or explained why the rationale for not doing it.

Sep 24 '18 15:09 winstonewert

I am actually not 100% sure why we chose this way. @carols10cents do you remember?

Jan 07 '19 19:01 steveklabnik

Any updates? That's an interesting point.

Jun 20 '19 14:06 davi2205

Any update @steveklabnik @carols10cents ?

Aug 04 '19 05:08 UnHumbleBen

I would say I feel better using Rc<RefCell<T>>. I'm building a small program which uses the Tree data structure and finally it looks like this:

  pub type TreeNodeWeak = Option<Weak<RefCell<Node>>>;                                                                                            
  pub type TreeNodeRc = Option<Rc<RefCell<Node>>>;

Most time, we need to do operations on the internal type T, the Rc, Weak and RefCell are just tools to allow us to do that. However, if we want to update a node in the tree, we will have to get a mutable reference, and Rc<RefCell<T>> is so much easier, especially when you also need to handle Weak<RefCell<T>>. So we can get an immutable reference from Rc, and then get a mutable reference from RefCell. In the other way (RefCell<Weak/Rc<T>>), we first need a mutable reference to Weak/Rc and get another mutable reference from Rc::get_mut(). Getting one more mutable reference is so much more code to write... Actually, I began the program with the example in the book, and I gave up that design very quickly and refactor the whole code to apply the change...

I think it's the difference between having multiple owners of the data (RefCell<Rc<T>>) and having multiple owners of the read-write reference(Rc<RefCell<T>>). I personally prefer the latter.

Aug 25 '19 04:08 lisanhu

fwiw https://stackoverflow.com/questions/57367092/what-is-the-difference-between-rcrefcellt-and-refcellrct

Mar 06 '20 13:03 anurbol

Elaborating on the link by @anurbol:

The situations are quite different. In the book's example, we want to enable adding and removing children to a node in the tree. RefCell<T> enables interior mutability for T, and it is the Vec<T> we want to modify (by adding and removing elements). It is each of the Nodes that we want to have multiple potential owners, hence the Rc around the node.

Putting RefCell inside the Rc presents two options.

Rc<Vec<RefCell<Node>>>: This would mean that we have multiple references to a single vector of Nodes, which can all be modified independently. We would not be able to add or remove elements to such a vector because it is inside Rc.

Rc<RefCell<Vec<Node>>>: This would mean that we have multiple references to a single modifiable vector of Nodes. Both the vector and each of the Nodes would be modifiable, but we'd be sharing the same list of children whenever we cloned (which isn't quite what we want either).

Sep 22 '20 21:09 curlywurlycraig

You're missing the option I'd suggest:

Vec<Rc<RefCell<Node>>

This option does allow you to add and remove children. The idea being that you always have a Rc<RefCell<Node>> and you can use .borrow_mut() and friends to get mutable access to any of the fields on Node including the children.

Sep 22 '20 22:09 winstonewert

That option only allows you to add and remove children if the Node isn't already wrapped in Rc<T>, which it will be if it appears within the tree. How would you modify the children of a node that is already a child? You can't own that Node while it's already referenced by an Rc in the tree, and thus you can't modify its children without RefCell::borrow_mut().

Good point though, I did miss that one.