Skip to content

Pin::new_unchecked docs need to warn about Ptr: Drop too #134874

Closed
@geofft

Description

@geofft

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 that Ptr type must implement Drop (as well as Deref and DerefMut)! 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 during Drop, Deref, or DerefMut implementations.

However, the doc for Pin::new_unchecked says

By using this method, you are also making a promise about the Deref and DerefMut implementations of Ptr, if they exist. Most importantly, they must not move out of their self 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    A-docsArea: Documentation for any part of the project, including the compiler, standard library, and toolsA-pinArea: PinT-libs-apiRelevant to the library API team, which will review and decide on the PR/issue.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions