Rust: Tracking Issue for Iterator::find_map

[KodrAus]

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

Implemented in https://github.com/rust-lang/rust/pull/49098

cc @matklad

[Amanieu]

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).

[shepmaster]

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))
})

[matklad]

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

[shepmaster]

what's the process? :)

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

[KodrAus]

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.

[alexcrichton]

@rfcbot fcp merge

Let's try again!

[rfcbot]

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

• [x] @Kimundi
• [x] @SimonSapin
• [x] @alexcrichton
• [x] @dtolnay
• [ ] @sfackler
• [ ] @withoutboats

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.

[rfcbot]

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

[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.

[matklad]

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.

[matklad]

optimistically send a stabilization PR: https://github.com/rust-lang/rust/pull/53385

[rfcbot]

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

[matklad]

closed by https://github.com/rust-lang/rust/pull/53385#issuecomment-415961283

[kennytm]

This function has been stabilized in 1.30.0