Repository navigation
Tracking Issue for Iterator::find_map #49602
Description
Activity
- addedT-libs-api[DEPRECATED; DO NOT USE][DEPRECATED; DO NOT USE]C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCCategory: An issue tracking the progress of sth. like the implementation of an RFC
on Apr 2, 2018 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).
Reacted by Alex Kladov and Jacob FinkelmanI 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)) })
Reacted by Josh StoneI 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?.
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.
Reacted by Jake Goulding@rfcbot fcp merge
Let's try again!
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.
- addedproposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.Proposed 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.This issue / PR is in PFCP or FCP with a disposition to merge it.
on Aug 12, 2018 🔔 This is now entering its final comment period, as per the review above. 🔔
- addedfinal-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.and removedproposed-final-comment-periodProposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.Proposed to merge/close by relevant subteam, see T-<team> label. Will enter FCP once signed off.
on Aug 14, 2018 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:::joinandItertools::group_by, and those APIs are probably more useful that find-map. However, the don't feel obviously right: join does not work withio::Write, andgroup_byhas this non-trivial buffering behavior.As for this method specifically, I've specified the
Itertoolsroute as an alternative in the original PR, together with arguments for why should it gostdlibdirectly, and a survey of real-world usages offind_map-like patterns.Reacted by Andre B. Reis and Ashley Mannixoptimistically send a stabilization PR: #53385
- addedfinished-final-comment-periodThe final comment period is finished for this PR / Issue.The final comment period is finished for this PR / Issue.and removedfinal-comment-periodIn the final comment period and will be merged soon unless new substantive objections are raised.In the final comment period and will be merged soon unless new substantive objections are raised.
on Aug 24, 2018 The final comment period, with a disposition to merge, as per the review above, is now complete.
- added a commit that references this issue
on Aug 25, 2018 closed by #53385 (comment)
This function has been stabilized in 1.30.0
Iterator::find_map, likefilter_mapbut for the first matching item in the iterator.Implemented in #49098
cc @matklad