-
Notifications
You must be signed in to change notification settings - Fork 13.9k
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
Ptralso carries with it implications on the way thatPtrtype must implementDrop(as well asDerefandDerefMut)! 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, orDerefMutimplementations.
However, the doc for Pin::new_unchecked says
By using this method, you are also making a promise about the
DerefandDerefMutimplementations ofPtr, if they exist. Most importantly, they must not move out of theirselfarguments: [...]
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.