|
4 | 4 | //! The type [`Rc<T>`][`Rc`] provides shared ownership of a value of type `T`, |
5 | 5 | //! allocated in the heap. Invoking [`clone`][clone] on [`Rc`] produces a new |
6 | 6 | //! pointer to the same allocation in the heap. When the last [`Rc`] pointer to a |
7 | | -//! given allocation is destroyed, the pointed-to value is also destroyed. |
| 7 | +//! given allocation is destroyed, the value stored in that allocation (often |
| 8 | +//! referred to as "inner value") is also dropped. |
8 | 9 | //! |
9 | 10 | //! Shared references in Rust disallow mutation by default, and [`Rc`] |
10 | 11 | //! is no exception: you cannot generally obtain a mutable reference to |
|
21 | 22 | //! |
22 | 23 | //! The [`downgrade`][downgrade] method can be used to create a non-owning |
23 | 24 | //! [`Weak`] pointer. A [`Weak`] pointer can be [`upgrade`][upgrade]d |
24 | | -//! to an [`Rc`], but this will return [`None`] if the allocation has |
25 | | -//! already been dropped. |
| 25 | +//! to an [`Rc`], but this will return [`None`] if the value stored in the allocation has |
| 26 | +//! already been dropped. In other words, `Weak` pointers do not keep the value |
| 27 | +//! inside the allocation alive; however, they *do* keep the allocation |
| 28 | +//! (the backing store for the value) alive. |
26 | 29 | //! |
27 | 30 | //! A cycle between [`Rc`] pointers will never be deallocated. For this reason, |
28 | 31 | //! [`Weak`] is used to break cycles. For example, a tree could have strong |
|
46 | 49 | //! |
47 | 50 | //! # Cloning references |
48 | 51 | //! |
49 | | -//! Creating a new reference from an existing reference counted pointer is done using the |
50 | | -//! `Clone` trait implemented for [`Rc<T>`][`Rc`] and [`Weak<T>`][`Weak`]. |
| 52 | +//! Creating a new reference to the same allocation as an existing reference counted pointer |
| 53 | +//! is done using the `Clone` trait implemented for [`Rc<T>`][`Rc`] and [`Weak<T>`][`Weak`]. |
51 | 54 | //! |
52 | 55 | //! ``` |
53 | 56 | //! use std::rc::Rc; |
|
109 | 112 | //! |
110 | 113 | //! // Despite dropping `gadget_owner`, we're still able to print out the name |
111 | 114 | //! // of the `Owner` of the `Gadget`s. This is because we've only dropped a |
112 | | -//! // single `Rc<Owner>`, not the `Owner` it points to. As long as there are |
113 | | -//! // other `Rc<Owner>` pointing at the same `Owner`, it will remain |
| 115 | +//! // single `Rc<Owner>`, not the `Owner` allocation it points to. As long as there are |
| 116 | +//! // other `Rc<Owner>` pointing at the same `Owner` allocation, it will remain |
114 | 117 | //! // allocated. The field projection `gadget1.owner.name` works because |
115 | 118 | //! // `Rc<Owner>` automatically dereferences to `Owner`. |
116 | 119 | //! println!("Gadget {} owned by {}", gadget1.id, gadget1.owner.name); |
@@ -365,7 +368,7 @@ impl<T> Rc<T> { |
365 | 368 | unsafe { Pin::new_unchecked(Rc::new(value)) } |
366 | 369 | } |
367 | 370 |
|
368 | | - /// Returns the contained value, if the `Rc` has exactly one strong reference. |
| 371 | + /// Returns the inner value, if the `Rc` has exactly one strong reference. |
369 | 372 | /// |
370 | 373 | /// Otherwise, an [`Err`][result] is returned with the same `Rc` that was |
371 | 374 | /// passed in. |
@@ -679,7 +682,7 @@ impl<T: ?Sized> Rc<T> { |
679 | 682 | /// mutate a shared value. |
680 | 683 | /// |
681 | 684 | /// See also [`make_mut`][make_mut], which will [`clone`][clone] |
682 | | - /// the inner value when it's shared. |
| 685 | + /// the inner value when there are other pointers. |
683 | 686 | /// |
684 | 687 | /// [weak]: struct.Weak.html |
685 | 688 | /// [`None`]: ../../std/option/enum.Option.html#variant.None |
@@ -1551,12 +1554,13 @@ impl<'a, T: 'a + Clone> RcFromIter<&'a T, slice::Iter<'a, T>> for Rc<[T]> { |
1551 | 1554 | /// |
1552 | 1555 | /// Since a `Weak` reference does not count towards ownership, it will not |
1553 | 1556 | /// prevent the value stored in the allocation from being dropped, and `Weak` itself makes no |
1554 | | -/// guarantees about the value still being present and may return [`None`] |
1555 | | -/// when [`upgrade`]d. |
| 1557 | +/// guarantees about the value still being present. Thus it may return [`None`] |
| 1558 | +/// when [`upgrade`]d. Note however that a `Weak` reference *does* prevent the allocation |
| 1559 | +/// itself (the backing store) from being deallocated. |
1556 | 1560 | /// |
1557 | 1561 | /// A `Weak` pointer is useful for keeping a temporary reference to the allocation |
1558 | | -/// managed by [`Rc`] without extending its lifetime. It is also used to prevent |
1559 | | -/// circular references between [`Rc`] pointers, since mutual owning references |
| 1562 | +/// managed by [`Rc`] without preventing its inner value from being dropped. It is also used to |
| 1563 | +/// prevent circular references between [`Rc`] pointers, since mutual owning references |
1560 | 1564 | /// would never allow either [`Rc`] to be dropped. For example, a tree could |
1561 | 1565 | /// have strong [`Rc`] pointers from parent nodes to children, and `Weak` |
1562 | 1566 | /// pointers from children back to their parents. |
|
0 commit comments