Skip to content

Tracking Issue for Iterator::find_map #49602

Description

@KodrAus

Iterator::find_map, like filter_map but for the first matching item in the iterator.

Implemented in #49098

cc @matklad

Activity

  1. added
    T-libs-api[DEPRECATED; DO NOT USE]
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    on Apr 2, 2018
  2. Amanieu commented on Apr 28, 2018

    @Amanieu
    Member

    I found this method useful when I had an array of several BinaryHeaps from which I needed to pop one item:

    while let Some(work_item) = work_lists.iter_mut().find_map(|h| h.pop()) {
        ...
    }

    Additionally, the order of the heaps in the array is significant, which this method handles perfectly (the first heap in the array has highest priority).

  3. shepmaster commented on May 10, 2018

    @shepmaster
    Member

    I have also found it useful.

    Before

    LENGTHS.flat_map(|length| {
        seeds
            .par_iter()
            .find_any(|&&seed| test_password(length, seed))
            .map(|&seed| (length, seed))
    }).next()

    After

    LENGTHS.find_map(|length| {
        seeds
            .par_iter()
            .find_any(|&&seed| test_password(length, seed))
            .map(|&seed| (length, seed))
    })
  4. matklad commented on Aug 9, 2018

    @matklad
    Contributor

    I wonder what are the next steps here? Are we ready to propose this for stabilization? If we are, what's the process? :)

  5. shepmaster commented on Aug 9, 2018

    @shepmaster
    Member

    what's the process? :)

    Code mechanics wise: So you want to stabilize a feature?.

  6. KodrAus commented on Aug 12, 2018

    @KodrAus
    ContributorAuthor

    This is a handy little method for iterators, that @matklad nicely motivated in the original PR. Shall we stabilize?

    @rfcbot fcp merge

    Pessimistically cc'ing @rust-lang/libs in case rfcbot ignores me.

  7. alexcrichton commented on Aug 12, 2018

    @alexcrichton
    Member

    @rfcbot fcp merge

    Let's try again!

  8. rfcbot commented on Aug 12, 2018

    @rfcbot

    Team member @alexcrichton has proposed to merge this. The next step is review by the rest of the tagged teams:

    No concerns currently listed.

    Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

    See this document for info about what commands tagged team members can give me.

  9. added
    proposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
    disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.
    on Aug 12, 2018
  10. rfcbot commented on Aug 14, 2018

    @rfcbot

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

  11. 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 Aug 14, 2018
  12. leonardo-m commented on Aug 15, 2018

    @leonardo-m

    The development strategy of this part of the standard library is broken. A better strategy should be: put the iterators you want in a external library (like itertools), and after a while of usage and testing and refinement move the top used iterators of the library/libraries into the std library. There are iterators in itertools that are far more used and far more useful than find_map, flatten and other things proposed to add or added to the std library.

  13. matklad commented on Aug 15, 2018

    @matklad
    Contributor

    Not a member of libs team, but I don't think there's mutual exclusion here. Moving most used methods from itertools to stdlib is an obviously good idea, and I think the only reason it's not done yet is that nobody has actually done the job of finding most useful methods, moving docs/tests/code to rust-lang and submitting PRs. If you could do this work, or maybe spearhead some "call for participation" style effort in this area, that would be absolutely awesome.

    The only thing to keep in mind is that number of usages shouldn't be the only criterion. I sort of feel that "the API feels 100% correct" is also important. I love Itertools:::join and Itertools::group_by, and those APIs are probably more useful that find-map. However, the don't feel obviously right: join does not work with io::Write, and group_by has this non-trivial buffering behavior.

    As for this method specifically, I've specified the Itertools route as an alternative in the original PR, together with arguments for why should it go stdlib directly, and a survey of real-world usages of find_map-like patterns.

  14. matklad commented on Aug 15, 2018

    @matklad
    Contributor

    optimistically send a stabilization PR: #53385

  15. added and removed
    final-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.
    on Aug 24, 2018
  16. rfcbot commented on Aug 24, 2018

    @rfcbot

    The final comment period, with a disposition to merge, as per the review above, is now complete.

  17. added a commit that references this issue on Aug 25, 2018
  18. matklad commented on Aug 25, 2018

    @matklad
    Contributor
  19. kennytm commented on Oct 27, 2018

    @kennytm
    Member

    This function has been stabilized in 1.30.0

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

    A-iteratorsArea: IteratorsC-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCT-libs-api[DEPRECATED; DO NOT USE]disposition-mergeThis issue / PR is in PFCP or FCP with a disposition to merge it.finished-final-comment-periodThe final comment period is finished for this PR / Issue.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions