|
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