Tracking Issue for Iterator::find_map

@matklad

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

Implemented in #49098

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

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

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

what's the process? :)

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

@matklad

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.

@rfcbot

@rfcbot fcp merge

Let's try again!

@alexcrichton

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.

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

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.

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.

optimistically send a stabilization PR: #53385

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

Auto merge of #53385 - matklad:stabilize-find-map, r=KodrAus

closed by #53385 (comment)

This function has been stabilized in 1.30.0

Navigation Menu

Tracking Issue for Iterator::find_map #49602

Before

After

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tracking Issue for Iterator::find_map #49602

Description

Activity

Amanieu commented on Apr 28, 2018

shepmaster commented on May 10, 2018

Before

After

matklad commented on Aug 9, 2018

shepmaster commented on Aug 9, 2018

KodrAus commented on Aug 12, 2018

alexcrichton commented on Aug 12, 2018

rfcbot commented on Aug 12, 2018

rfcbot commented on Aug 14, 2018

leonardo-m commented on Aug 15, 2018

matklad commented on Aug 15, 2018

matklad commented on Aug 15, 2018

rfcbot commented on Aug 24, 2018

matklad commented on Aug 25, 2018

kennytm commented on Oct 27, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions