Skip to content

Commit 220aa78

Browse files
John-Mark Allenjmaargh
John-Mark Allen
authored andcommitted
Re-draft DerefMut docs in-line with Deref
1 parent 7b7ebe7 commit 220aa78

File tree

1 file changed

+32
-19
lines changed

1 file changed

+32
-19
lines changed

library/core/src/ops/deref.rs

Lines changed: 32 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -167,42 +167,55 @@ impl<T: ?Sized> Deref for &mut T {
167167
/// In addition to being used for explicit dereferencing operations with the
168168
/// (unary) `*` operator in mutable contexts, `DerefMut` is also used implicitly
169169
/// by the compiler in many circumstances. This mechanism is called
170-
/// ['`Deref` coercion'][more]. In immutable contexts, [`Deref`] is used.
170+
/// ["mutable deref coercion"][coercion]. In immutable contexts, [`Deref`] is used.
171171
///
172-
/// Implementing `DerefMut` for smart pointers makes mutating the data behind
173-
/// them convenient, which is why they implement `DerefMut`. On the other hand,
174-
/// the rules regarding [`Deref`] and `DerefMut` were designed specifically to
175-
/// accommodate smart pointers. Because of this, **`DerefMut` should only be
176-
/// implemented for smart pointers** to avoid confusion.
177-
///
178-
/// For similar reasons, **this trait should never fail**. Failure during
179-
/// dereferencing can be extremely confusing when `DerefMut` is invoked
180-
/// implicitly.
172+
/// **Warning:** Deref coercion is a powerful language feature which has
173+
/// far-reaching implications for every type that implements `DerefMut`. The
174+
/// compiler will silently insert calls to `DerefMut::deref_mut`. For this
175+
/// reason, one should be careful about implementing `DerefMut` and only do so
176+
/// when mutable deref coercion is desirable. See [the `Deref` docs][implementing]
177+
/// for advice on when this is typically desirable or undesirable.
181178
///
182-
/// Violating these requirements is a logic error. The behavior resulting from a logic error is not
183-
/// specified, but users of the trait must ensure that such logic errors do *not* result in
184-
/// undefined behavior. This means that `unsafe` code **must not** rely on the correctness of this
185-
/// method.
179+
/// Types that implement `DerefMut` or `Deref` are often called "smart
180+
/// pointers" and the mechanism of deref coercion has been specifically designed
181+
/// to facilitate the pointer-like behaviour that name suggests. Often, the
182+
/// purpose of a "smart pointer" type is to change the ownership semantics
183+
/// of a contained value (for example, [`Rc`][rc] or [`Cow`][cow]) or the
184+
/// storage semantics of a contained value (for example, [`Box`][box]).
186185
///
187-
/// # More on `Deref` coercion
186+
/// # Mutable deref coercion
188187
///
189-
/// If `T` implements `DerefMut<Target = U>`, and `x` is a value of type `T`,
188+
/// If `T` implements `DerefMut<Target = U>`, and `v` is a value of type `T`,
190189
/// then:
191190
///
192-
/// * In mutable contexts, `*x` (where `T` is neither a reference nor a raw pointer)
193-
/// is equivalent to `*DerefMut::deref_mut(&mut x)`.
191+
/// * In mutable contexts, `*v` (where `T` is neither a reference nor a raw pointer)
192+
/// is equivalent to `*DerefMut::deref_mut(&mut v)`.
194193
/// * Values of type `&mut T` are coerced to values of type `&mut U`
195194
/// * `T` implicitly implements all the (mutable) methods of the type `U`.
196195
///
197196
/// For more details, visit [the chapter in *The Rust Programming Language*][book]
198197
/// as well as the reference sections on [the dereference operator][ref-deref-op],
199198
/// [method resolution] and [type coercions].
200199
///
200+
/// # Fallibility
201+
///
202+
/// **This trait's method should never unexpectedly fail**. Deref coercion means
203+
/// the compiler will often insert calls to `DerefMut::deref_mut` implicitly.
204+
/// Failure during dereferencing can be extremely confusing when `DerefMut` is
205+
/// invoked implicitly. In the majority of uses it should be infallible, though
206+
/// it may be acceptable to panic if the type is misused through programmer
207+
/// error, for example.
208+
///
201209
/// [book]: ../../book/ch15-02-deref.html
202-
/// [more]: #more-on-deref-coercion
210+
/// [coercion]: #mutable-deref-coercion
211+
/// [implementing]: trait.Deref.html#when-to-implement-deref-or-derefmut
203212
/// [ref-deref-op]: ../../reference/expressions/operator-expr.html#the-dereference-operator
204213
/// [method resolution]: ../../reference/expressions/method-call-expr.html
205214
/// [type coercions]: ../../reference/type-coercions.html
215+
/// [box]: ../../alloc/boxed/struct.Box.html
216+
/// [string]: ../../alloc/string/struct.String.html
217+
/// [rc]: ../../alloc/rc/struct.Rc.html
218+
/// [cow]: ../../alloc/borrow/enum.Cow.html
206219
///
207220
/// # Examples
208221
///

0 commit comments

Comments
 (0)