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:
bors 2023-09-25 03:50:59 +00:00
commit 8c04c06317

View File

@ -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: