Repository navigation
Tracking Issue for Iterator::try_find #63178
Description
Adds try_find to Iterator.
PR: #63177
fn try_find<F, E, R>(&mut self, f: F) -> Result<Option<Self::Item>, E>
where
F: FnMut(&Self::Item) -> R,
R: Try<Ok = bool, Error = E>;Open questions:
- Decide on just-
Result, vs potentially supportingOptionand otherTrytypes Decide on generic-ness of functions likeIterator::try_findandarray::try_map#85115 - Final commenting period (FCP)
- Stabilization PR
Activity
[-]Tracking Issue for Iterator::find_result[/-][+]Tracking Issue for Iterator::try_find[/+]Auto merge of #63177 - MOZGIII:find-result, r=Amanieu
MOZGIII commentedon Jan 4, 2020
I'll start test-running it in the field. The next step for this feature would be to allow coupling the resulting
Trytype with the closure return type. Apparently, GAT would allow a way to implement this.mikeyhew commentedon Aug 20, 2020
Is there an easy workaround to use until this is stabilized?
MOZGIII commentedon Aug 20, 2020
You can use this crate for now: https://github.com/MOZGIII/iter-try-rs
mikeyhew commentedon Aug 25, 2020
@MOZGIII thanks. I realized I had a
.mapcall after the.findthat I was replacing, so I switched to.filter_map(...).transpose()?scottmcm commentedon May 7, 2021
Wanted to drop a mention of https://rust-lang.github.io/rfcs/3058-try-trait-v2.html#possibilities-for-try_find in here -- figuring out exactly how this should work is probably a blocker for stabilization here (just Result, just things compatible with Result, like
Poll<Result<_, _>>, anything in a family ofTrytypes that can acceptOption<_>as the Output type...)Jesse-Bakker commentedon Nov 21, 2022
With the resolution of #85115, are there any issues blocking stabilization, besides stabilization of
ops::Residual?MOZGIII commentedon Nov 21, 2022
Thanks for the update!
I'd say we can go ahead with the stabilization.
Ciel-MC commentedon Aug 24, 2023
Hello, why this hasn't been stabilized yet?
MOZGIII commentedon Aug 24, 2023
Indeed, I'll send a PR to it forward when I have time, hopefully this week
scottmcm commentedon Aug 28, 2023
Note that this, like
array::try_from_fnandIterator::try_collectand similar, depends on theResidualtrait mechanism for mapping fromFoo<A>toFoo<[A; N]>, which is not used in any stable functions right now, so stabilization here is a bigger question than just the specific function in question.See #94119 (comment) where
array::from_fnwas accepted butarray::try_from_fnwasn't accepted due to this.MOZGIII commentedon Sep 2, 2023
Thanks for the feedback, I wasn't aware of this
Residualblocker...Also, I have realized I didn't exactly follow the procedure for the stabilization, so I'll have to read up on that before creating the PR itself (and trigger the final comment period and etc).
Also, we have GAT now, so we might want to revisit the design.
It might make sense to organize the stabilization of this feature in a larger chunk of work around the stabilization of the
Residualtrait (UPD: which istry_trait_v2apparently), together with the other things that are blocked by it.Should we create a new tracking issue, or bring it up in the
Residualtracking issue?At the same time, we did have situations in the past where certain traits were unstable while other stable things depended on them (for instance, the
try/?itself). So, maybe this is not so big of a concern?MOZGIII commentedon Mar 4, 2025
Hey, it seems like this keeps slipping though the cracks for me. Anyone wants to pick this up and move to completion?