|
17 | 17 | //! - Having one mutable reference (`&mut T`) to the object (also know as Mutability).
|
18 | 18 | //!
|
19 | 19 | //! This is enforced by the Rust compiler. However, there are situations where this rule is not
|
20 |
| -//! flexible enough. Sometimes is required to have multiple references to an object and yet |
| 20 | +//! flexible enough. Sometimes is required to have multiple references to an object and yet |
21 | 21 | //! mutate it.
|
22 | 22 | //!
|
23 | 23 | //! Shareable mutable containers exist to permit mutability in presence of aliasing in a
|
24 | 24 | //! controlled manner. Both `Cell<T>` and `RefCell<T>` allows to do this in a single threaded
|
25 |
| -//! way, you can mutate them using an inmutable reference. However, neither `Cell<T>` nor |
26 |
| -//! `RefCell<T>` are thread safe (they do not implement `Sync`), if you need to do Aliasing and |
27 |
| -//! Mutation between multiple threads is possible to use `Mutex`, `RwLock` or `AtomicXXX`. |
| 25 | +//! way. However, neither `Cell<T>` nor `RefCell<T>` are thread safe (they do not implement |
| 26 | +//! `Sync`), if you need to do Aliasing and Mutation between multiple threads is possible to use |
| 27 | +//! `Mutex`, `RwLock` or `AtomicXXX`. |
28 | 28 | //!
|
29 | 29 | //! Values of the `Cell<T>` and `RefCell<T>` types may be mutated through shared references (i.e.
|
30 | 30 | //! the common `&T` type), whereas most Rust types can only be mutated through unique (`&mut T`)
|
31 | 31 | //! references. We say that `Cell<T>` and `RefCell<T>` provide 'interior mutability', in contrast
|
32 |
| -//! with typical Rust types that exhibit 'inherited mutability'. |
| 32 | +//! with typical Rust types that exhibit 'inherited mutability'. |
33 | 33 | //!
|
34 | 34 | //! Cell types come in two flavors: `Cell<T>` and `RefCell<T>`. `Cell<T>` implements interior
|
35 | 35 | //! mutability by moving values in and out of the `Cell<T>`. To use references instead of values,
|
|
0 commit comments