Tracking Issue for Iterator::try_reduce (feature iterator_try_reduce)

33f20bd
Opened by kit at 2023-03-25 15:58:42

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

  • [ ] Final comment period (FCP)

  • [ ] Stabilization PR

Unresolved Questions

  • None yet.

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

    • [x] Implementation: #87054

    • [ ] Final comment period (FCP)

    • [ ] Stabilization PR

    Unresolved Questions

    • None yet.

    kit at 2021-07-11 05:57:09

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

    Xiretza at 2022-06-09 18:26:08

  3. I'd like this to be stabilised as well.

    Rua at 2022-11-04 09:52:06

  4. Stabilization Report

    Implementation History

    • This method was implemented in #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

    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.

    Xiretza at 2022-12-11 20:34:10

  5. 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 https://github.com/rust-lang/rust/pull/94119#issuecomment-1090685583, 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 https://github.com/rust-lang/rfcs/pull/3233#discussion_r815183078 -- I don't know if there's a way to actually do it, but one of you might have a bright idea.)

    scottmcm at 2023-01-08 17:23:43

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

    Josh Triplett at 2023-01-17 16:41:16

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

    Josh Triplett at 2023-01-17 16:41:22

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

    Simon Varey at 2023-03-25 01:31:16

  9. Never mind, I was mistaken on that point

    Simon Varey at 2023-03-25 15:58:42