Skip to content

Commit 7c9c712

Browse files
fu5haManishearth
authored andcommittedJan 7, 2024
improve structural Unpin + formatting
1 parent e2e8746 commit 7c9c712

File tree

1 file changed

+10
-8
lines changed

1 file changed

+10
-8
lines changed
 

‎library/core/src/pin.rs

+10-8
Original file line numberDiff line numberDiff line change
@@ -753,9 +753,11 @@
753753
//! 1. *Structural [`Unpin`].* A struct can be [`Unpin`] if, and only if, all of its
754754
//! structurally-pinned fields are, too. This is [`Unpin`]'s behavior by default.
755755
//! However, as a libray author, it is your responsibility not to write something like
756-
//! <code>unsafe impl\<T> [Unpin] for Struct\<T> {}</code>. (Adding *any* projection
757-
//! operation requires unsafe code, so the fact that [`Unpin`] is a safe trait does not break
758-
//! the principle that you only have to worry about any of this if you use [`unsafe`].)
756+
//! <code>impl\<T> [Unpin] for Struct\<T> {}</code> and then offer a method that provides
757+
//! structural pinning to an inner field of `T`, which may not be [`Unpin`]! (Adding *any*
758+
//! projection operation requires unsafe code, so the fact that [`Unpin`] is a safe trait does
759+
//! not break the principle that you only have to worry about any of this if you use
760+
//! [`unsafe`].)
759761
//!
760762
//! 2. *Pinned Destruction.* As discussed [above][drop-impl], [`drop`] takes
761763
//! [`&mut self`], but the struct (and hence its fields) might have been pinned
@@ -764,14 +766,14 @@
764766
//!
765767
//! As a consequence, the struct *must not* be [`#[repr(packed)]`][packed].
766768
//!
767-
//! 3. *Structural Notice of Destruction.* You must uphold the the [`Drop` guarantee][drop-guarantee]:
768-
//! once your struct is pinned, the struct's storage cannot be re-used without calling the
769-
//! structurally-pinned fields' destructors, as well.
769+
//! 3. *Structural Notice of Destruction.* You must uphold the the
770+
//! [`Drop` guarantee][drop-guarantee]: once your struct is pinned, the struct's storage cannot
771+
//! be re-used without calling the structurally-pinned fields' destructors, as well.
770772
//!
771773
//! This can be tricky, as witnessed by [`VecDeque<T>`]: the destructor of [`VecDeque<T>`]
772774
//! can fail to call [`drop`] on all elements if one of the destructors panics. This violates
773-
//! the [`Drop` guarantee][drop-guarantee], because it can lead to elements being deallocated without
774-
//! their destructor being called.
775+
//! the [`Drop` guarantee][drop-guarantee], because it can lead to elements being deallocated
776+
//! without their destructor being called.
775777
//!
776778
//! [`VecDeque<T>`] has no pinning projections, so its destructor is sound. If it wanted
777779
//! to provide such structural pinning, its destructor would need to abort the process if any

0 commit comments

Comments
 (0)
Failed to load comments.