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 task
MOZGIII opened this issue Aug 1, 2019 · 5 comments
Open
1 task

Tracking Issue for Iterator::try_find #63178

MOZGIII opened this issue Aug 1, 2019 · 5 comments
Labels
A-iterators B-unstable C-tracking-issue Libs-Small Libs-Tracked requires-nightly T-libs-api

Comments

@MOZGIII
Copy link
Contributor

@MOZGIII 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:

  • Decide on just-Result, vs potentially supporting Option and other Try types #85115
@jonas-schievink jonas-schievink added A-iterators B-unstable C-tracking-issue T-libs-api 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 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 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-Tracked labels Jul 29, 2020
@mikeyhew
Copy link
Contributor

@mikeyhew mikeyhew commented Aug 20, 2020

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

@MOZGIII
Copy link
Contributor Author

@MOZGIII MOZGIII commented Aug 20, 2020

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

@mikeyhew
Copy link
Contributor

@mikeyhew mikeyhew commented Aug 25, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-iterators B-unstable C-tracking-issue Libs-Small Libs-Tracked requires-nightly T-libs-api
Projects
None yet
Development

No branches or pull requests

6 participants