Rust's trait system does not allow orphans: roughly, every
impl must live
either in the crate that defines the trait or the implementing
type. Consequently, crates that define new types should eagerly implement all
applicable, common traits.
To see why, consider the following situation:
Url, without implementing
webappimports from both
There is no way for
webapp to add
url, since it defines neither.
(Note: the newtype pattern can provide an efficient, but inconvenient
workaround; see newtype for views)
The most important common traits to implement from
Clone, Show, Hash, Eq
[FIXME]. This guideline is in flux while the "opt-in" nature of built-in traits is being decided. See https://github.com/rust-lang/rfcs/pull/127
Deriving saves implementation effort, makes correctness trivial, and automatically adapts to upstream changes.
Operators with built in syntax (
|, and so on) can be provided for a type
by implementing the traits in
core::ops. These operators come with strong
Mul only for an operation that bears some resemblance
to multiplication (and shares the expected properties, e.g. associativity), and
so on for the other traits.
Drop trait is treated specially by the compiler as a way of
associating destructors with types. See
the section on destructors for
Deref traits are used implicitly by the compiler in many circumstances,
and interact with method resolution. The relevant rules are designed
specifically to accommodate smart pointers, and so the traits should be used
only for that purpose.
Deref traits are invoked implicitly by the compiler in sometimes
subtle ways, failure during dereferencing can be extremely confusing. If a
dereference might not succeed, target the
Deref trait as a
Option type instead.
The rules around method resolution and
Deref are in flux, but inherent methods
on a type implementing
Deref are likely to shadow any methods of the referent
with the same name.