Tracking Issue for Iterator::try_reduce (feature iterator_try_reduce)

[kit-981]

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_reduce method to the Iterator trait #87054
• Final comment period (FCP)
• Stabilization PR

Unresolved Questions

• None yet.

[Xiretza]

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]

I'd like this to be stabilised as well.

[Xiretza]

Stabilization Report

Implementation History

• This method was implemented in Add a try_reduce method 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

• greptimedb
• Optimized solution to Advent of Code 2022 day9

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]

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]

@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]

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.