Skip to content

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

New issue

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

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

Already on GitHub? # to your account

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: 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.

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: 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 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
Contributor

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 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 Nominated for discussion during a libs-api team meeting. label Jan 31, 2023
@simonvarey

This comment was marked as resolved.

@simonvarey

This comment was marked as resolved.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
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.
Projects
None yet
Development

No branches or pull requests

7 participants