Description
Location
https://doc.rust-lang.org/std/pin/struct.Pin.html#method.new_unchecked
Summary
The pin
module-level doc says
It should further be noted that creating a pinning pointer of some type
Ptr
also carries with it implications on the way thatPtr
type must implementDrop
(as well asDeref
andDerefMut
)! When implementing a pointer type that may be used as a pinning pointer, you must also take the same care described above not to move out of or otherwise invalidate the pointee duringDrop
,Deref
, orDerefMut
implementations.
However, the doc for Pin::new_unchecked
says
By using this method, you are also making a promise about the
Deref
andDerefMut
implementations ofPtr
, if they exist. Most importantly, they must not move out of theirself
arguments: [...]
If I understand correctly (which I may well not, given the subject matter...), these two sections are talking about the same thing: there are some safe traits that you implement by writing a method that takes a bare &mut self
, and when those traits are implemented for the Ptr
type in a Pin<Ptr<T>>
, unless T: Unpin
, you really need to treat that &mut self
as if it were pinned (maybe by stuffing it inside a Pin
ASAP), or you are in danger of breaking invariants that unsafe code is allowed to assume. And because this is a safety requirement, there's got to be an unsafe
somewhere stating that you believe those safe traits are implemented appropriately, and that place is, I think, the invocation of Pin::new_unchecked
for a specific choice of Ptr
type.
But the doc for Pin::new_unchecked
only mentions Deref
and DerefMut
as part of the safety contract of invoking it. If these sections are talking about the same thing, then properly implementing Drop
is also part of the safety burden and the doc should mention it.