One backwards paragraph about weak references in Chapter 15.6

[ktvoelker]

trafficstars

There is a paragraph in Chapter 15.6 that seems to be saying the opposite of what it should:

Thinking about the relationships another way, a parent node should own its children: if a parent node is dropped, its child nodes should be dropped as well. However, a child should not own its parent: if we drop a child node, the parent should still exist. This is a case for weak references!

If a parent node is dropped, its child nodes are still valid trees of their own. This is true at a conceptual level (a subtree is also a tree), but looking at it in a Rust-specific way, nodes in this example reference their children via Rc, which means a node is not necessarily the sole owner of its children.

Consider also the final code example in this chapter, under the heading "Visualizing Changes to strong_count and weak_count". It creates a child and a parent. Then, the parent goes out of scope and is dropped, after which the child still exists. The child's weak reference to the parent is examined, showing that the child no longer has a parent.

I am still very new at Rust, so it's possible that I am just massively misunderstanding what's going on here. But it seems pretty clear to me.

[carols10cents]

It's more like "if the parent node gets dropped/disconnected from the tree (and should be cleaned up), then its child nodes should also be cleaned up, if the parent was the last owner of each child node."

However, if the root of the tree (a parent that itself doesn't have any parents) has all its children dropped, the root should not automatically be dropped when its last child is.

Does that make sense? Do you have any suggestions on how to clarify this?

[ktvoelker]

Note: the source link in my issue description was broken, but the paragraph in question still exists, and I have fixed the source link to be a permalink.

It's more like "if the parent node gets dropped/disconnected from the tree (and should be cleaned up), then its child nodes should also be cleaned up, if the parent was the last owner of each child node."

This makes sense. The "if the parent was the last owner" bit is really important here because the whole chapter is talking about Rc<T> values which can have multiple owners.

However, if the root of the tree (a parent that itself doesn't have any parents) has all its children dropped, the root should not automatically be dropped when its last child is.

I'm not so sure about this part. If the child is still referenced by a parent, it can't be dropped. In order for the child node to end up dropped, you'd first have to remove it from all lists of children it appears in. But that means that by the time the node is being dropped, it has already stopped being a child node. This is what makes "dropping a child" seem like a confusing way to talk about this situation.

Perhaps it could say something like this:

"However, if a child node is removed from a tree, that should not cause its former parent to be dropped, even if the child has no other owners and thus does end up dropped."

Does that make sense? Do you have any suggestions on how to clarify this?

I think it's possible to make the paragraph in question less confusing, and the suggestions we've accumulated here would do that. But I'm also wondering if the paragraph is even necessary. What value is it trying to add? It's not part of the main narrative flow of that section - it's an aside trying to restate the main point in a different way. And obviously that can be valuable...but not if the restatement is confusing and ends up leading people astray.

[skoocda]

I just finished this chapter and I'd echo the sentiment shared by @ktvoelker here.

If the point of the example is to demonstrate this flow:

a parent node should own its children: if a parent node is dropped, its child nodes should be dropped as well

My suggestion is to rewrite the example so that a parent node is introduced first, then a child node is added after, then either:

1. both are cleaned up when the parent node goes out of scope.
2. the child node is removed and cleaned up without affecting the parent

This would align better with the intention of the preface.