rust-lang / rust-lang/rust

Tracking issue for pin ergonomics

Open
#130,494 5 comments 19 reactions 2 assignees View on GitHub

@traviscross is already working on this.

Since Mar 4, 2025.

B-experimental C-tracking-issue F-pin_ergonomics T-lang
Dominant language
Rust
Stars
119k
Forks
16.1k
PR merge metrics
PR metrics pending

Description

This is a tracking issue for work on pin ergonomics.

The feature gate for the issue is #![feature(pin_ergonomics)].

Design sketch

The basic pin projection rules that we're working toward are:

Alternative B:

  • If T: Unpin, &pin mut T and &mut T coerce to each other.
  • If a struct, enum, or union(?) defining a type T is annotated with #[pin_v2] (todo bikeshedding), then:
    • Projection of &pin mut T to &pin mut T.U is allowed.
    • If T: Drop , the Drop impl must use fn drop(&pin mut self).
    • No manual impls of Unpin are allowed on T.
    • The user must ensure that, given a pinned reference to T, the pinning contract is upheld for all ?Unpin fields of T.

(The rules apply likewise for &pin const T.)

Beyond pin projection, the basic overall idea of pin ergonomics is that &pin mut T (and &pin const T) should be integrated in the same sense as &mut T, in that reborrowing works, autoref works, corresponding binding modes exist, and that the borrow checker will track and ensure that once a &pin mut T is taken (even if no longer live) that we can't later get a &mut T or move T.

Alternative A

The original proposal, now labeled Alternative A, was:

  • If T: Unpin, &pin mut T and &mut T coerce to each other.
  • If T: Drop + !Unpin, require the Drop impl for T to use fn drop(&pin mut self).
  • Projection of &pin mut T to &pin mut T.U is allowed if either T: !Unpin or U: Unpin.

These rules are factored differently (using coercions (see here) and the fact that we haven't stabilized negative impls yet), but have the same effect as the rules in Niko's otherwise similar MinPin proposal.

About tracking issues

Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

Steps
Unresolved Questions
  • Apparently this gives special semantics to the Unpin trait (at least, the compiler uses is_unpin checks in &pin handling). That is a safe trait and hence cannot be deeply semantically meaningful. Is this coherent?
Related

TODO.

cc @eholk @rust-lang/lang

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.