Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tracking Issue for Iterator::try_find #63178

Open
1 of 3 tasks
MOZGIII opened this issue Aug 1, 2019 · 11 comments
Open
1 of 3 tasks

Tracking Issue for Iterator::try_find #63178

MOZGIII opened this issue Aug 1, 2019 · 11 comments
Labels
A-iterators Area: Iterators B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC Libs-Small Libs issues that are considered "small" or self-contained Libs-Tracked Libs issues that are tracked on the team's project board. requires-nightly This issue requires a nightly compiler in some way. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@MOZGIII
Copy link
Contributor

MOZGIII commented Aug 1, 2019

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:

@jonas-schievink jonas-schievink added A-iterators Area: Iterators B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Aug 1, 2019
@MOZGIII MOZGIII changed the title Tracking Issue for Iterator::find_result Tracking Issue for Iterator::try_find Aug 6, 2019
@Centril Centril added the requires-nightly This issue requires a nightly compiler in some way. label Aug 8, 2019
bors added a commit that referenced this issue Jan 2, 2020
Add Iterator::try_find

I found a need for this fn, and created this PR.

Tracking issue: #63178

I did a fair amount of thinking about the function name, and settled on the current one.
I don't see other anything else that's non-trivial here, but I'm open for debate. I just want this functionality to be there.
It couples with the `collect` trick for collecting `Result<Vec<T>, E>` from `Iterator<Item = Result<T, E>>`.

UPD:

I've already looked at `fallible_iterator` crate, but I don't think it supports my use case.
The main problem is that I can't construct a failable iterator. I have a regular iterator, and I just need to apply a predicate that can fail via `find` method.

UPD: `fallible_iterator` would work, but it's not elegant cause I'd have to make a failable iterator by mapping iterator with `Result::Ok` first.
@MOZGIII
Copy link
Contributor Author

MOZGIII commented 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 Try type with the closure return type. Apparently, GAT would allow a way to implement this.

@KodrAus KodrAus added Libs-Small Libs issues that are considered "small" or self-contained Libs-Tracked Libs issues that are tracked on the team's project board. labels Jul 29, 2020
@mikeyhew
Copy link
Contributor

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

@MOZGIII
Copy link
Contributor Author

MOZGIII commented Aug 20, 2020

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

@mikeyhew
Copy link
Contributor

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

@scottmcm
Copy link
Member

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

@Jesse-Bakker
Copy link
Contributor

Jesse-Bakker commented Nov 21, 2022

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

@MOZGIII
Copy link
Contributor Author

MOZGIII commented Nov 21, 2022

Thanks for the update!

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

@Ciel-MC
Copy link

Ciel-MC commented Aug 24, 2023

Hello, why this hasn't been stabilized yet?

@MOZGIII
Copy link
Contributor Author

MOZGIII commented Aug 24, 2023

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

@scottmcm
Copy link
Member

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
Copy link
Contributor Author

MOZGIII commented Sep 2, 2023

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-iterators Area: Iterators B-unstable Blocker: Implemented in the nightly compiler and unstable. C-tracking-issue Category: An issue tracking the progress of sth. like the implementation of an RFC Libs-Small Libs issues that are considered "small" or self-contained Libs-Tracked Libs issues that are tracked on the team's project board. requires-nightly This issue requires a nightly compiler in some way. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants