|
3 | 3 | /// In addition to being used for explicit dereferencing operations with the
|
4 | 4 | /// (unary) `*` operator in immutable contexts, `Deref` is also used implicitly
|
5 | 5 | /// by the compiler in many circumstances. This mechanism is called
|
6 |
| -/// ['`Deref` coercion'][more]. In mutable contexts, [`DerefMut`] is used. |
7 |
| -/// |
8 |
| -/// Implementing `Deref` for smart pointers makes accessing the data behind them |
9 |
| -/// convenient, which is why they implement `Deref`. On the other hand, the |
10 |
| -/// rules regarding `Deref` and [`DerefMut`] were designed specifically to |
11 |
| -/// accommodate smart pointers. Because of this, **`Deref` should only be |
12 |
| -/// implemented for smart pointers** to avoid confusion. |
13 |
| -/// |
14 |
| -/// For similar reasons, **this trait should never fail**. Failure during |
| 6 | +/// ['`Deref` coercion'][more]. In mutable contexts, [`DerefMut`] is used and |
| 7 | +/// mutable deref coercion similarly occurs. |
| 8 | +/// |
| 9 | +/// Deref coercion is a powerful language feature and has far-reaching |
| 10 | +/// implications for every type implementing `Deref`: the compiler will often |
| 11 | +/// implicitly call `Deref::deref`, as described [below][more]. For this reason, |
| 12 | +/// `Deref` should not be implemented unless all of the implications of coercion |
| 13 | +/// are understood and desired. Implementing `Deref` is most commonly desirable |
| 14 | +/// when a type |
| 15 | +/// |
| 16 | +/// 1. should transparently behave like a contained value; and |
| 17 | +/// 2. does not have a rich set of methods in of itself, to avoid conflict or |
| 18 | +/// confusion with methods on the `Target` type. |
| 19 | +/// |
| 20 | +/// For example, [`Box<T>`][box] is perhaps the canonical example for `Deref`: |
| 21 | +/// a `Box<T>` value **is** a `T` value that is heap-allocated, so deref |
| 22 | +/// coercion intuitively makes `Box<T>` act like `T`. `Box<T>` |
| 23 | +/// also has very few methods (though several associated functions), so it is |
| 24 | +/// unlikely that users will find conflict with methods on their target type. |
| 25 | +/// [`RefCell<T>`][refcell] also contains a value of `T`, but while it could |
| 26 | +/// implement `DerefMut`, it does not since there is a rich API of methods to |
| 27 | +/// explicitly manage the owned value: allowing deref coercion in this case |
| 28 | +/// would hide the explicit management and likely cause confusion. |
| 29 | +/// |
| 30 | +/// Types that implement `Deref` and `DerefMut` are often called "smart |
| 31 | +/// pointers" and the mechanism of deref coercion has been specifically designed |
| 32 | +/// to facilitate the pointer-like behaviour that name suggests. Very often, the |
| 33 | +/// only purpose of a "smart pointer" type is to change the ownership semantics |
| 34 | +/// of a contained value (for example, [`Rc`][rc] or [`Cow`][cow]) or the |
| 35 | +/// storage semantics of a contained value (for example, [`Box`][box]). |
| 36 | +/// |
| 37 | +/// If deref coercion is not desirable, the [`AsRef`] or [`Borrow`][borrow] |
| 38 | +/// traits are alternatives which should be preferred in most cases. |
| 39 | +/// |
| 40 | +/// # Fallibility |
| 41 | +/// |
| 42 | +/// **This trait's method should never fail**. Deref coercion means the compiler |
| 43 | +/// will often implicitly call `Deref::deref`. Failure during |
15 | 44 | /// dereferencing can be extremely confusing when `Deref` is invoked implicitly.
|
16 | 45 | ///
|
17 | 46 | /// # More on `Deref` coercion
|
|
21 | 50 | /// * In immutable contexts, `*x` (where `T` is neither a reference nor a raw pointer)
|
22 | 51 | /// is equivalent to `*Deref::deref(&x)`.
|
23 | 52 | /// * Values of type `&T` are coerced to values of type `&U`
|
24 |
| -/// * `T` implicitly implements all the (immutable) methods of the type `U`. |
| 53 | +/// * `T` implicitly implements all the methods of the type `U` which take the |
| 54 | +/// `&self` receiver. |
25 | 55 | ///
|
26 | 56 | /// For more details, visit [the chapter in *The Rust Programming Language*][book]
|
27 | 57 | /// as well as the reference sections on [the dereference operator][ref-deref-op],
|
|
32 | 62 | /// [ref-deref-op]: ../../reference/expressions/operator-expr.html#the-dereference-operator
|
33 | 63 | /// [method resolution]: ../../reference/expressions/method-call-expr.html
|
34 | 64 | /// [type coercions]: ../../reference/type-coercions.html
|
| 65 | +/// [box]: ../../std/boxed/struct.Box.html |
| 66 | +/// [refcell]: ../../std/cell/struct.RefCell.html |
| 67 | +/// [rc]: ../../std/rc/struct.Rc.html |
| 68 | +/// [cow]: ../../std/borrow/enum.Cow.html |
| 69 | +/// [borrow]: ../../std/borrow/trait.Borrow.html |
35 | 70 | ///
|
36 | 71 | /// # Examples
|
37 | 72 | ///
|
|
0 commit comments