mirror of
https://github.com/rust-lang/rust.git
synced 2024-11-02 07:22:42 +00:00
Auto merge of #116074 - fzs111:clarify-pin-docs, r=Mark-Simulacrum
Clarify example in `Pin::new_unchecked` docs This example in the docs of `Pin::new_unchecked` puzzled me for a relatively long time. Now I understand that it comes down to the difference between dropping the `Pin` vs dropping the pinned value. I have extended the explanation to highlight this difference. In my opinion it is clearer now, and I hope it helps others understand `Pin` better.
This commit is contained in:
commit
8c04c06317
@ -572,7 +572,10 @@ impl<P: Deref> Pin<P> {
|
||||
/// // though we have previously pinned it! We have violated the pinning API contract.
|
||||
/// }
|
||||
/// ```
|
||||
/// A value, once pinned, must remain pinned forever (unless its type implements `Unpin`).
|
||||
/// A value, once pinned, must remain pinned until it is dropped (unless its type implements
|
||||
/// `Unpin`). Because `Pin<&mut T>` does not own the value, dropping the `Pin` will not drop
|
||||
/// the value and will not end the pinning contract. So moving the value after dropping the
|
||||
/// `Pin<&mut T>` is still a violation of the API contract.
|
||||
///
|
||||
/// Similarly, calling `Pin::new_unchecked` on an `Rc<T>` is unsafe because there could be
|
||||
/// aliases to the same data that are not subject to the pinning restrictions:
|
||||
|
Loading…
Reference in New Issue
Block a user