Skip to content

Tracking issue for RFC 2132: copy_closures/clone_closures #44490

Closed
Closed
Tracking issue for RFC 2132: copy_closures/clone_closures#44490
Labels
B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCE-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.T-langRelevant to the language teamWG-epochWorking group: Epoch (2018) managementfinal-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.

Description

@aturon
aturon
opened on Sep 11, 2017

This is a tracking issue for the RFC "Copy/Clone Closures" (rust-lang/rfcs#2132).

Steps:

Activity

  1. aturon
    added
    B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.
    T-langRelevant to the language team
    on Sep 11, 2017

  2. nikomatsakis commented on Sep 13, 2017

    @nikomatsakis
    nikomatsakis
    on Sep 13, 2017
    Contributor

    I believe that @scalexm has implemented this RFC already. =)

  3. arielb1 commented on Sep 13, 2017

    @arielb1
    arielb1
    on Sep 13, 2017
    Contributor

    @nmatsakis

    That was for tuples, not for closures.

  4. nikomatsakis commented on Sep 14, 2017

    @nikomatsakis
    nikomatsakis
    on Sep 14, 2017
    Contributor

    @arielb1 I was referring to #44551

  5. TimNN
    added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Sep 17, 2017
  6. bors
    added a commit that references this issue on Sep 21, 2017

    Auto merge of #44551 - scalexm:copy-clone-closures, r=arielb1

    e2504cf

  7. scalexm commented on Sep 25, 2017

    @scalexm
    scalexm
    on Sep 25, 2017
    Contributor

    (I think we can tick the first box)

  8. nikomatsakis commented on Oct 16, 2017

    @nikomatsakis
    nikomatsakis
    on Oct 16, 2017
    Contributor

    What do we want to do around stabilization here? @cramertj was floating the idea of stabilizing only the clone impl for closures, not the copy one, at least until such time as we have a workable "unexpected copy" lint that would push you to invoke clone when copying closures (but that lint probably wants a bit of design).

    Personally, I think I'd be ok stabilizing copy/clone closures in their entirety, but we probably want to see a bit more usage in the wild.

    Can anyone report on using this feature?

  9. cramertj commented on Oct 16, 2017

    @cramertj
    cramertj
    on Oct 16, 2017
    Member

    I've been messing with it in some personal stuff, and I've really enjoyed having the feature. I'd be in favor of stabilizing both Copy and Clone.

  10. mbrubeck
    changed the title [-]Tracking issue for RFC 2132: Copy/Clone Closures[/-] [+]Tracking issue for RFC 2132: copy_closures/clone_closures[/+] on Nov 17, 2017
  11. mbrubeck
    added
    B-unstableBlocker: Implemented in the nightly compiler and unstable.
    on Nov 17, 2017

  12. tuxmark5 commented on Nov 24, 2017

    @tuxmark5
    tuxmark5
    on Nov 24, 2017

    Any plans to extend this to support cloning generators as well?

  13. solson commented on Dec 9, 2017

    @solson
    solson
    on Dec 9, 2017
    Contributor

    I haven't used this directly yet, but I can definitely report that people have complained to me that we don't have this feature on stable yet because it's unnecessarily forced them to change their design. It solves one of those irritating "when you want it, you really want it" problems, imo. :)

  14. alercah commented on Feb 10, 2018

    @alercah
    alercah
    on Feb 10, 2018

    What's the status on this? Is it ready to stabilize once docs are ready? I'm planning a rewrite of some closure-related docs in the reference, so if this is going in, I'll include that.

  15. 5 remaining items

  16. cramertj commented on Feb 23, 2018

    @cramertj
    cramertj
    on Feb 23, 2018
    Member

    Yes, you're correct-- I should have said non-move closures which do not mutate or move captured variables are copy.

  17. rfcbot
    added
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    and removed
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    on Feb 23, 2018

  18. rfcbot commented on Feb 23, 2018

    @rfcbot
    rfcbot
    on Feb 23, 2018

    🔔 This is now entering its final comment period, as per the review above. 🔔

  19. rfcbot commented on Mar 5, 2018

    @rfcbot
    rfcbot
    on Mar 5, 2018

    The final comment period is now complete.

  20. nikomatsakis
    added
    E-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
    on Mar 7, 2018

  21. nikomatsakis commented on Mar 7, 2018

    @nikomatsakis
    nikomatsakis
    on Mar 7, 2018
    Contributor

    I marked as E-mentor -- looks like we're ready for a stabilization PR here, right? There are instructions on the forge.

  22. nikomatsakis
    added
    WG-epochWorking group: Epoch (2018) management
    on Mar 7, 2018

  23. alercah commented on Mar 7, 2018

    @alercah
    alercah
    on Mar 7, 2018

    The reference is already updated. RBE probably doesn't need updating, the stdlib could maybe use mention on Copy and Clone traits, and I'm unsure about the book. @steveklabnik?

  24. nikomatsakis commented on Mar 8, 2018

    @nikomatsakis
    nikomatsakis
    on Mar 8, 2018
    Contributor

    @alercah sounds right

  25. SimonSapin commented on Mar 23, 2018

    @SimonSapin
    SimonSapin
    on Mar 23, 2018
    Contributor

    Stabilization PR (with mention in docs for Clone and Copy): #49299

  26. kennytm
    added 2 commits that reference this issue on Mar 24, 2018

    Rollup merge of rust-lang#49299 - SimonSapin:ubiquity, r=nikomatsakis

    02d6f64

    Rollup merge of rust-lang#49299 - SimonSapin:ubiquity, r=nikomatsakis

    297a6e5

  27. SimonSapin commented on Mar 24, 2018

    @SimonSapin
    SimonSapin
    on Mar 24, 2018
    Contributor

    #49299 is merged, I think this is it. Let me know if I forgot something relevant to this tracking issue.

  28. SimonSapin
    closed this as completedon Mar 24, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    B-RFC-approvedBlocker: Approved by a merged RFC but not yet implemented.B-unstableBlocker: Implemented in the nightly compiler and unstable.C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCE-mentorCall for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.T-langRelevant to the language teamWG-epochWorking group: Epoch (2018) managementfinal-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions