|
158 | 158 | //! is called *even if your type was previously pinned*! It is as if the
|
159 | 159 | //! compiler automatically called `get_unchecked_mut`.
|
160 | 160 | //!
|
161 |
| -//! This can never cause a problem in safe code because implementing a type that relies on pinning |
162 |
| -//! requires unsafe code, but be aware that deciding to make use of pinning |
163 |
| -//! in your type (for example by implementing some operation on `Pin<&[mut] Self>`) |
164 |
| -//! has consequences for your `Drop` implementation as well: if an element |
165 |
| -//! of your type could have been pinned, you must treat Drop as implicitly taking |
166 |
| -//! `Pin<&mut Self>`. |
| 161 | +//! This can never cause a problem in safe code because implementing a type that |
| 162 | +//! relies on pinning requires unsafe code, but be aware that deciding to make |
| 163 | +//! use of pinning in your type (for example by implementing some operation on |
| 164 | +//! `Pin<&Self>` or `Pin<&mut Self>`) has consequences for your `Drop` |
| 165 | +//! implementation as well: if an element of your type could have been pinned, |
| 166 | +//! you must treat Drop as implicitly taking `Pin<&mut Self>`. |
167 | 167 | //!
|
168 | 168 | //! In particular, if your type is `#[repr(packed)]`, the compiler will automatically
|
169 | 169 | //! move fields around to be able to drop them. As a consequence, you cannot use
|
170 | 170 | //! pinning with a `#[repr(packed)]` type.
|
171 | 171 | //!
|
172 | 172 | //! # Projections and Structural Pinning
|
173 | 173 | //!
|
174 |
| -//! One interesting question arises when considering the interaction of pinning and |
175 |
| -//! the fields of a struct. When can a struct have a "pinning projection", i.e., |
176 |
| -//! an operation with type `fn(Pin<&[mut] Struct>) -> Pin<&[mut] Field>`? |
177 |
| -//! In a similar vein, when can a generic wrapper type (such as `Vec<T>`, `Box<T>`, or `RefCell<T>`) |
178 |
| -//! have an operation with type `fn(Pin<&[mut] Wrapper<T>>) -> Pin<&[mut] T>`? |
| 174 | +//! One interesting question arises when considering the interaction of pinning |
| 175 | +//! and the fields of a struct. When can a struct have a "pinning projection", |
| 176 | +//! i.e., an operation with type `fn(Pin<&Struct>) -> Pin<&Field>`? In a |
| 177 | +//! similar vein, when can a generic wrapper type (such as `Vec<T>`, `Box<T>`, |
| 178 | +//! or `RefCell<T>`) have an operation with type `fn(Pin<&Wrapper<T>>) -> |
| 179 | +//! Pin<&T>`? |
| 180 | +//! |
| 181 | +//! Note: For the entirety of this discussion, the same applies for mutable references as it |
| 182 | +//! does for shared references. |
179 | 183 | //!
|
180 | 184 | //! Having a pinning projection for some field means that pinning is "structural":
|
181 | 185 | //! when the wrapper is pinned, the field must be considered pinned, too.
|
182 |
| -//! After all, the pinning projection lets us get a `Pin<&[mut] Field>`. |
| 186 | +//! After all, the pinning projection lets us get a `Pin<&Field>`. |
183 | 187 | //!
|
184 | 188 | //! However, structural pinning comes with a few extra requirements, so not all
|
185 | 189 | //! wrappers can be structural and hence not all wrappers can offer pinning projections:
|
|
0 commit comments