mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Rephrase unpin docs in terms of pinning-agnosticness

Browse Source
This commit is contained in:
Manish Goregaokar 2024-01-06 16:10:03 -08:00
parent 058fb50ecd
commit 0050676440
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
library/core/src/marker.rs
View File

@ -899,13 +899,15 @@ impl<T: ?Sized> !Freeze for UnsafeCell<T> {}
{T: ?Sized} &mut T,
}
/// Types that do not need to follow the rules of pinning.
/// Types that do not require any pinning guarantees.
///
/// For information on what "pinning" is, see the [`pin` module] documentation.
///
/// Implementing the `Unpin` trait for `T` lifts the restrictions of pinning off that type.
/// This means that, if `T: Unpin`, it cannot be assumed that a value of type `T` will be bound
/// by the invariants that pinning infers, *even* when "pinned" by a [`Pin<Ptr>`] pointing at it.
/// Implementing the `Unpin` trait for `T` expresses the fact that `T` is pinning-agnostic:
/// it shall not expose nor rely on any pinning guarantees. This, in turn, means that a
/// `Pin`-wrapped pointer to such a type can feature a *fully unrestricted* API.
/// In other words, if `T: Unpin`, a value of type `T` will *not* be bound by the invariants
/// which pinning otherwise offers, even when "pinned" by a [`Pin<Ptr>`] pointing at it.
/// When a value of type `T` is pointed at by a [`Pin<Ptr>`], [`Pin`] will not restrict access
/// to the pointee value like it normally would, thus allowing the user to do anything that they
/// normally could with a non-[`Pin`]-wrapped `Ptr` to that value.