pub trait DerefMut: Deref {
// Required method
fn deref_mut(&mut self) -> &mut Self::Target;
}
Expand description
Used for mutable dereferencing operations, like in *v = 1;
.
In addition to being used for explicit dereferencing operations with the
(unary) *
operator in mutable contexts, DerefMut
is also used implicitly
by the compiler in many circumstances. This mechanism is called
“mutable deref coercion”. In immutable contexts, Deref
is used.
Warning: Deref coercion is a powerful language feature which has
far-reaching implications for every type that implements DerefMut
. The
compiler will silently insert calls to DerefMut::deref_mut
. For this
reason, one should be careful about implementing DerefMut
and only do so
when mutable deref coercion is desirable. See the Deref
docs
for advice on when this is typically desirable or undesirable.
Types that implement DerefMut
or Deref
are often called “smart
pointers” and the mechanism of deref coercion has been specifically designed
to facilitate the pointer-like behaviour that name suggests. Often, the
purpose of a “smart pointer” type is to change the ownership semantics
of a contained value (for example, Rc
or Cow
) or the
storage semantics of a contained value (for example, Box
).
§Mutable deref coercion
If T
implements DerefMut<Target = U>
, and v
is a value of type T
,
then:
- In mutable contexts,
*v
(whereT
is neither a reference nor a raw pointer) is equivalent to*DerefMut::deref_mut(&mut v)
. - Values of type
&mut T
are coerced to values of type&mut U
T
implicitly implements all the (mutable) methods of the typeU
.
For more details, visit the chapter in The Rust Programming Language as well as the reference sections on the dereference operator, method resolution and type coercions.
§Fallibility
This trait’s method should never unexpectedly fail. Deref coercion means
the compiler will often insert calls to DerefMut::deref_mut
implicitly.
Failure during dereferencing can be extremely confusing when DerefMut
is
invoked implicitly. In the majority of uses it should be infallible, though
it may be acceptable to panic if the type is misused through programmer
error, for example.
However, infallibility is not enforced and therefore not guaranteed.
As such, unsafe
code should not rely on infallibility in general for
soundness.
§Examples
A struct with a single field which is modifiable by dereferencing the struct.
use std::ops::{Deref, DerefMut};
struct DerefMutExample<T> {
value: T
}
impl<T> Deref for DerefMutExample<T> {
type Target = T;
fn deref(&self) -> &Self::Target {
&self.value
}
}
impl<T> DerefMut for DerefMutExample<T> {
fn deref_mut(&mut self) -> &mut Self::Target {
&mut self.value
}
}
let mut x = DerefMutExample { value: 'a' };
*x = 'b';
assert_eq!('b', x.value);
Run