Tracking Issue for Iterator::try_find

[MOZGIII]

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 supporting Option and other Try types Decide on generic-ness of functions like Iterator::try_find and array::try_map #85115
• Final commenting period (FCP)
• Stabilization PR

[MOZGIII]

I'll start test-running it in the field. The next step for this feature would be to allow coupling the resulting Try type with the closure return type. Apparently, GAT would allow a way to implement this.

[mikeyhew]

Is there an easy workaround to use until this is stabilized?

[MOZGIII]

You can use this crate for now: https://github.com/MOZGIII/iter-try-rs

[mikeyhew]

@MOZGIII thanks. I realized I had a .map call after the .find that I was replacing, so I switched to .filter_map(...).transpose()?

[scottmcm]

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 of Try types that can accept Option<_> as the Output type...)

[Jesse-Bakker]

With the resolution of #85115, are there any issues blocking stabilization, besides stabilization of ops::Residual?

[MOZGIII]

Thanks for the update!

I'd say we can go ahead with the stabilization.

[Ciel-MC]

Hello, why this hasn't been stabilized yet?

[MOZGIII]

Indeed, I'll send a PR to it forward when I have time, hopefully this week

[scottmcm]

Note that this, like array::try_from_fn and Iterator::try_collect and similar, depends on the Residual trait mechanism for mapping from Foo<A> to Foo<[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_fn was accepted but array::try_from_fn wasn't accepted due to this.

[MOZGIII]

Thanks for the feedback, I wasn't aware of this Residual blocker...
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 Residual trait (UPD: which is try_trait_v2 apparently), together with the other things that are blocked by it.
Should we create a new tracking issue, or bring it up in the Residual tracking 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?