|
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