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_reduce (feature iterator_try_reduce) #87053

Open
1 of 3 tasks
kit-981 opened this issue Jul 11, 2021 · 8 comments
Open
1 of 3 tasks

Tracking Issue for Iterator::try_reduce (feature iterator_try_reduce) #87053

kit-981 opened this issue Jul 11, 2021 · 8 comments
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@kit-981
Copy link
Contributor

kit-981 commented Jul 11, 2021

Feature gate: #![feature(iterator_try_reduce)]

This is a tracking issue for adding a try_reduce method to the Iteratortrait. There is foldand try_fold but only reduce. It's possible for users to use try_fold directly but it's also possible to use fold directly instead of reduce. I reason that if reduce exists that a fallible try_reduce should also exist to encourage the safe handling of errors.

I use the Try trait as suggested by @sinkuu here for a similar feature.

Steps / History

Unresolved Questions

  • None yet.
@kit-981 kit-981 added C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. labels Jul 11, 2021
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Dec 4, 2021
Add a `try_reduce` method to the Iterator trait

Tracking issue: rust-lang#87053
@Xiretza
Copy link
Contributor

Xiretza commented Jun 9, 2022

Can we get this toward stabilization? It's been in nightly for about half a year now, and I can't find any issues related to it.

@Rua
Copy link

Rua commented Nov 4, 2022

I'd like this to be stabilised as well.

@ghost ghost mentioned this issue Nov 7, 2022
@Xiretza
Copy link
Contributor

Xiretza commented Dec 11, 2022

Stabilization Report

Implementation History

API Summary

A summary of the API can be found in the std documentation.

Experience Report

Example Usages

The method is being used as a fairly straightforward short-circuiting version of reduce(); both to abort on errors and to avoid unnecessary iteration when no more work needs to be done.

It has been part of nightly for over a year now, no related issues have been opened since. I think it should be safe to stabilize.

@scottmcm scottmcm added the I-libs-api-nominated Indicates that an issue has been nominated for discussion during a libs-api team meeting. label Jan 8, 2023
@scottmcm
Copy link
Member

scottmcm commented Jan 8, 2023

Nominated for libs-api discussion of the stabilization request above. Two important discussion topics for you:

  • This uses the ops::Residual mechanism, which kept array::try_from_fn from stabilizing in Stabilize array_from_fn #94119 (comment), and I don't know if anything had changed since then.

  • There's an RFC open for more methods like this (try_all and try_any), so accepting this might be precedent for things like that. I don't know if there's a way that they could all be abstracted behind something generic, but it'd be cool if there was a way to not need new methods for all of these. (I discuss this a bit in RFC: add try_all and try_any to Iterator rfcs#3233 (comment) -- I don't know if there's a way to actually do it, but one of you might have a bright idea.)

@joshtriplett
Copy link
Member

@scottmcm We discussed this in today's @rust-lang/libs-api meeting. We had the same concerns about Try/Residual that we did with array_from_fn, and don't want to move forward with stabilizing this until Try feels a bit less in flux. We didn't know what the state of evolving Try was.

@joshtriplett
Copy link
Member

Also, there was a lot of interest in having a generic solution to avoid proliferating try_ methods. I personally would love to see "closures that can explicitly affect control flow" added, if we have a clear design for them.

@m-ou-se m-ou-se removed the I-libs-api-nominated Indicates that an issue has been nominated for discussion during a libs-api team meeting. label Jan 31, 2023
@simonvarey
Copy link

I just opened #109578 which notes a type inference which seems to be missing in try_reduce.

@simonvarey
Copy link

Never mind, I was mistaken on that point

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. 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

7 participants