Skip to content

Tracking issue for pin ergonomics #130494

Open
4 of 4 issues completed
Open

Description

@traviscross

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

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    I-lang-nominatedNominated for discussion during a lang team meeting.
    T-langRelevant to the language team
    on Sep 17, 2024
  2. changed the title [-]Tracking Issue for pin ergonomics[/-] [+]Tracking issue for pin ergonomics[/+] on Sep 17, 2024
  3. added
    B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).
    on Sep 18, 2024
  4. traviscross commented on Sep 19, 2024

    @traviscross
    ContributorAuthor

    We accepted this experiment in the 2024-09-18 lang triage meeting.

    Thanks to @eholk for pushing this forward.

  5. added a commit that references this issue on Sep 20, 2024
  6. added a commit that references this issue on Sep 20, 2024
  7. added a commit that references this issue on Oct 2, 2024
  8. added a commit that references this issue on Oct 5, 2024
  9. added a commit that references this issue on Oct 5, 2024
  10. added a commit that references this issue on Oct 15, 2024
  11. 50 remaining items

  12. added a commit that references this issue on May 15, 2026
  13. added a commit that references this issue on May 15, 2026
  14. added 2 commits that reference this issue on May 15, 2026
  15. added a commit that references this issue on May 16, 2026
  16. P8L1 commented on May 16, 2026

    @P8L1
    Contributor

    Update: fn drop(&pin mut self) sugar has now landed in #156452.

    This implements fn drop(&pin mut self) as sugar for Drop::pin_drop: resolver performs the effective pin_drop lookup, and AST lowering validates that the sugar is being used for the actual Drop lang trait before lowering accepted cases to pin_drop.

  17. added a commit that references this issue on Jun 8, 2026
  18. added a commit that references this issue on Jun 9, 2026
  19. P8L1 commented on Jun 9, 2026

    @P8L1
    Contributor

    I see there are a lot of pin_v2 issues. For tracking, I just want to get more attention on #153693, which forbids &pin borrows for ADTs without #[pin_v2], and I have a strong suspicion it will solve some of the current issues. Although it seems to me like the PR is dead, it has been waiting on review for 1 month now.

  20. added a commit that references this issue on Aug 29, 2026
  21. added a commit that references this issue on Aug 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

B-experimentalBlocker: In-tree experiment; RFC pending, not yet approved or unneeded (requires FCP to stabilize).C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCF-pin_ergonomics`#![feature(pin_ergonomics)]`T-langRelevant to the language team

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions