Open kit-981 opened 3 years ago
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.
I'd like this to be stabilised as well.
A summary of the API can be found in the std documentation.
Example Usages
greptimedb
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.
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 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.
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.
I just opened #109578 which notes a type inference which seems to be missing in try_reduce
.
Never mind, I was mistaken on that point
Feature gate:
#![feature(iterator_try_reduce)]
This is a tracking issue for adding a
try_reduce
method to theIterator
trait. There isfold
andtry_fold
but onlyreduce
. It's possible for users to usetry_fold
directly but it's also possible to usefold
directly instead ofreduce
. I reason that ifreduce
exists that a fallibletry_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