|
182 | 182 | //! } |
183 | 183 | //! } |
184 | 184 | //! ``` |
185 | | -//! `inner_drop` has the type that `drop` *should* have, so this makes sure that |
| 185 | +//! The function `inner_drop` has the type that `drop` *should* have, so this makes sure that |
186 | 186 | //! you do not accidentally use `self`/`this` in a way that is in conflict with pinning. |
187 | 187 | //! |
188 | 188 | //! Moreover, if your type is `#[repr(packed)]`, the compiler will automatically |
|
196 | 196 | //! The usual approach is to write helper methods (so called *projections*) |
197 | 197 | //! that turn `Pin<&mut Struct>` into a reference to the field, but what |
198 | 198 | //! type should that reference have? Is it `Pin<&mut Field>` or `&mut Field`? |
199 | | -//! The same question arises with the fields of an enum, and also when considering |
| 199 | +//! The same question arises with the fields of an `enum`, and also when considering |
200 | 200 | //! container/wrapper types such as [`Vec<T>`], [`Box<T>`], or [`RefCell<T>`]. |
201 | 201 | //! (This question applies to both mutable and shared references, we just |
202 | 202 | //! use the more common case of mutable references here for illustration.) |
|
209 | 209 | //! pinning removed as part of the projection. If both are done for the same field, |
210 | 210 | //! that will likely be unsound! |
211 | 211 | //! |
212 | | -//! Basically, as the author of a data structure you get to decide for each field whether pinning |
| 212 | +//! As the author of a data structure you get to decide for each field whether pinning |
213 | 213 | //! "propagates" to this field or not. Pinning that propagates is also called "structural", |
214 | 214 | //! because it follows the structure of the type. |
215 | 215 | //! In the following, we describe the considerations that have to be made for either choice. |
|
235 | 235 | //! ``` |
236 | 236 | //! |
237 | 237 | //! You may also `impl Unpin for Struct` *even if* the type of `field` |
238 | | -//! is not `Unpin`. What that type thinks about pinning is just not relevant |
| 238 | +//! is not `Unpin`. What that type thinks about pinning is not relevant |
239 | 239 | //! when no `Pin<&mut Field>` is ever created. |
240 | 240 | //! |
241 | 241 | //! ## Pinning *is* structural for `field` |
|
0 commit comments