Repository navigation
About fallible iterators #844
Description
I just created the label "fallible-iterator" and labelled (only opened) related issues and pull requests where the iterator item is fallible: results mostly, options too.
It's one recurring topic, and a proper discussion might be useful.
To start, I think our adaptors of iterators of results should be _ok-suffixed.
try_-prefixed should be reserved to methods tied to the currently unstable Try trait.
Activity
jswrenn commentedon Jan 12, 2024
I'd like to take the approach described in #814 (comment); i.e.:
Trytrait and implement it forOptionandResult.maybe_.Tryis stabilized, we (hopefully) simply delete our fork ofTryand depend on the standard library one.With this approach, we can give users a cutting-edge experience without increasing our MSRV. And, by using the
maybe_prefix, we can also freely introduce new methods without worrying of conflicting with future additions to the standard library.Philippe-Cholet commentedon Jan 12, 2024
From #814 (comment)
so I think it's natural to copy part (here
Tryrelated parts) of the std as we simply want to expand it.I would largely prefer
try_-prefixed names overmaybe_but I reckon that avoid conflict with libcore is more important, with RFC2845 implemented or not.jswrenn commentedon Jan 16, 2024
Yes, avoiding conflict with libcore is important, and it's why I'm recommending using the
maybe_prefix. Without RFC2845 implemented, the conflict would cause a compile error. With RFC2845 implemented, our implementations would shadow the standard library's, but almost certainly be sub-optimal in implementation (e.g., for anytry_methods stabilized before theTrytrait, we can't delegate to the stdlib'stry_methods in our own implementations, since we couldn't replicate the stdlib'sTrybound).Philippe-Cholet commentedon Jan 18, 2024
@phimuemue What do you think on this matter?
What would be the inconvenients of using Rust nightly (for one feature only)? As we would be able to use the
Trytrait and specializetry_fold. (We would still have to copy some parts such asNeverShortCircuitbut not much).It would require to have the nightly toolchain installed (I currently don't), which might "intimidate" new contributors.
Copy things would not limit us about our MSRV (as we could copy more recent things).
I'm not very familiar with nightly (and history on why itertools went to stable in the first place), what am I missing?
phimuemue commentedon Jan 18, 2024
I think replicating Try in itertools is fine.
I’m not an expert on how we implement it in a waterproof way that does not leak the details (the „pub-in-priv“ thing), but I think it is possible (at least to a certain extent).
Maybe I misunderstand you, @Philippe-Cholet, but I do not see why nightly would be required (especially for the average contributor).
Regarding ok vs maybe, I have no preference, but I’d like to be consistent.
Philippe-Cholet commentedon Jan 18, 2024
Instead of copy/paste, if we were to use the nightly unstable feature related to
Try(just wondering) then "what would be the inconvenients?" was my question.phimuemue commentedon Jan 18, 2024
Ah, I see. I am reluctant to use nightly (don’t want to do conditional compilation if not strictly necessary).
Philippe-Cholet commentedon Jan 18, 2024
So we agree on jswrenn proposition. Then
Tryand all our new fallible iterators (similar to the "adaptors" module/folder).try_collectfor a newmaybe_collect? (It would solve the conflict with nightly.)process_resultsfor a newmaybe_process(or justmaybe)?_okmethods for newmaybe_methods?Iterator(andItertools) methods should have amaybe_variant? Because there is quite a zoo. For now, only the ones having an_okvariant I guess. We might want to define a clear limit later.cuviper commentedon Feb 2, 2024
FWIW,
rayonalso uses a privateTryfor its public methods liketry_fold. You're welcome to copy it:https://github.com/rayon-rs/rayon/blob/5876c80e1208c0aae60092ddfa690a71709e326d/src/iter/mod.rs#L3388
(and
rayondoesn't have the same constraints for wanting to avoidstdmethod names likeItertoolsdoes.)