clarify that unsafe code must not rely on our safe traits
This commit is contained in:
parent
ab45885dec
commit
62111145b7
@ -63,6 +63,11 @@
|
||||
/// (transitive) impls are not forced to exist, but these requirements apply
|
||||
/// whenever they do exist.
|
||||
///
|
||||
/// Violating these requirements is a logic error. The behavior resulting from a logic error is not
|
||||
/// specified, but users of the trait must ensure that such logic errors do *not* result in
|
||||
/// undefined behavior. This means that `unsafe` code **must not** rely on the correctness of these
|
||||
/// methods.
|
||||
///
|
||||
/// ## Derivable
|
||||
///
|
||||
/// This trait can be used with `#[derive]`. When `derive`d on structs, two
|
||||
@ -250,6 +255,11 @@ fn ne(&self, other: &Rhs) -> bool {
|
||||
/// This property cannot be checked by the compiler, and therefore `Eq` implies
|
||||
/// [`PartialEq`], and has no extra methods.
|
||||
///
|
||||
/// Violating this property is a logic error. The behavior resulting from a logic error is not
|
||||
/// specified, but users of the trait must ensure that such logic errors do *not* result in
|
||||
/// undefined behavior. This means that `unsafe` code **must not** rely on the correctness of these
|
||||
/// methods.
|
||||
///
|
||||
/// ## Derivable
|
||||
///
|
||||
/// This trait can be used with `#[derive]`. When `derive`d, because `Eq` has
|
||||
@ -656,6 +666,11 @@ fn clone_from(&mut self, other: &Self) {
|
||||
/// It's easy to accidentally make `cmp` and `partial_cmp` disagree by
|
||||
/// deriving some of the traits and manually implementing others.
|
||||
///
|
||||
/// Violating these requirements is a logic error. The behavior resulting from a logic error is not
|
||||
/// specified, but users of the trait must ensure that such logic errors do *not* result in
|
||||
/// undefined behavior. This means that `unsafe` code **must not** rely on the correctness of these
|
||||
/// methods.
|
||||
///
|
||||
/// ## Corollaries
|
||||
///
|
||||
/// From the above and the requirements of `PartialOrd`, it follows that `<` defines a strict total order.
|
||||
@ -889,6 +904,11 @@ fn clamp(self, min: Self, max: Self) -> Self
|
||||
/// transitively: if `T: PartialOrd<U>` and `U: PartialOrd<V>` then `U: PartialOrd<T>` and `T:
|
||||
/// PartialOrd<V>`.
|
||||
///
|
||||
/// Violating these requirements is a logic error. The behavior resulting from a logic error is not
|
||||
/// specified, but users of the trait must ensure that such logic errors do *not* result in
|
||||
/// undefined behavior. This means that `unsafe` code **must not** rely on the correctness of these
|
||||
/// methods.
|
||||
///
|
||||
/// ## Corollaries
|
||||
///
|
||||
/// The following corollaries follow from the above requirements:
|
||||
|
@ -153,6 +153,11 @@
|
||||
/// Thankfully, you won't need to worry about upholding this property when
|
||||
/// deriving both [`Eq`] and `Hash` with `#[derive(PartialEq, Eq, Hash)]`.
|
||||
///
|
||||
/// Violating this property is a logic error. The behavior resulting from a logic error is not
|
||||
/// specified, but users of the trait must ensure that such logic errors do *not* result in
|
||||
/// undefined behavior. This means that `unsafe` code **must not** rely on the correctness of these
|
||||
/// methods.
|
||||
///
|
||||
/// ## Prefix collisions
|
||||
///
|
||||
/// Implementations of `hash` should ensure that the data they
|
||||
|
@ -14,6 +14,11 @@
|
||||
/// For similar reasons, **this trait should never fail**. Failure during
|
||||
/// dereferencing can be extremely confusing when `Deref` is invoked implicitly.
|
||||
///
|
||||
/// Violating these requirements is a logic error. The behavior resulting from a logic error is not
|
||||
/// specified, but users of the trait must ensure that such logic errors do *not* result in
|
||||
/// undefined behavior. This means that `unsafe` code **must not** rely on the correctness of this
|
||||
/// method.
|
||||
///
|
||||
/// # More on `Deref` coercion
|
||||
///
|
||||
/// If `T` implements `Deref<Target = U>`, and `x` is a value of type `T`, then:
|
||||
@ -114,6 +119,11 @@ fn deref(&self) -> &T {
|
||||
/// dereferencing can be extremely confusing when `DerefMut` is invoked
|
||||
/// implicitly.
|
||||
///
|
||||
/// Violating these requirements is a logic error. The behavior resulting from a logic error is not
|
||||
/// specified, but users of the trait must ensure that such logic errors do *not* result in
|
||||
/// undefined behavior. This means that `unsafe` code **must not** rely on the correctness of this
|
||||
/// method.
|
||||
///
|
||||
/// # More on `Deref` coercion
|
||||
///
|
||||
/// If `T` implements `DerefMut<Target = U>`, and `x` is a value of type `T`,
|
||||
|
Loading…
Reference in New Issue
Block a user