Repository navigation
Tracking Issue for Iterator::try_reduce (feature iterator_try_reduce) #87053
Description
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
- Implementation: Add a
try_reducemethod to the Iterator trait #87054 - Final comment period (FCP)
- Stabilization PR
Unresolved Questions
- None yet.
Activity
Rollup merge of rust-lang#87054 - kit-981:master, r=scottmcm
Xiretza commentedon 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 commentedon Nov 4, 2022
I'd like this to be stabilised as well.
Xiretza commentedon Dec 11, 2022
Stabilization Report
Implementation History
try_reducemethod to the Iterator trait #87054, first released as part of 1.59.API Summary
A summary of the API can be found in the std documentation.
Experience Report
Example Usages
greptimedbAdvent of Code 2022 day9The 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 commentedon Jan 8, 2023
Nominated for libs-api discussion of the stabilization request above. Two important discussion topics for you:
This uses the
ops::Residualmechanism, which keptarray::try_from_fnfrom stabilizing in Stabilizearray_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_allandtry_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: addtry_allandtry_anytoIteratorrfcs#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 commentedon Jan 17, 2023
@scottmcm We discussed this in today's @rust-lang/libs-api meeting. We had the same concerns about
Try/Residualthat we did witharray_from_fn, and don't want to move forward with stabilizing this untilTryfeels a bit less in flux. We didn't know what the state of evolvingTrywas.joshtriplett commentedon Jan 17, 2023
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.simonvarey commentedon Mar 25, 2023
simonvarey commentedon Mar 25, 2023
bmanev18 commentedon Jan 12, 2026
Will the method be available in stable? I have followed #87054, but nothing hints at a future release. Even though it is just a wrapper of
try_fold(), a standalone method would always be better.