Open Philippe-Cholet opened 8 months ago
I'd like to take the approach described in https://github.com/rust-itertools/itertools/pull/814#discussion_r1439725414; i.e.:
Try
trait and implement it for Option
and Result
.maybe_
.Try
is stabilized, we (hopefully) simply delete our fork of Try
and 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.
From https://github.com/rust-itertools/itertools/pull/814#discussion_r1439867108
In libcore,
fold
is usually specialized usingtry_fold
specializations alongside withNeverShortCircuit
which surely won't be public forever so I thought that we would copy it at some point.
so I think it's natural to copy part (here Try
related parts) of the std as we simply want to expand it.
I would largely prefer try_
-prefixed names over maybe_
but I reckon that avoid conflict with libcore is more important, with RFC2845 implemented or not.
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 any try_
methods stabilized before the Try
trait, we can't delegate to the stdlib's try_
methods in our own implementations, since we couldn't replicate the stdlib's Try
bound).
@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 Try
trait and specialize try_fold
. (We would still have to copy some parts such as NeverShortCircuit
but 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?
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.
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.
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.
Ah, I see. I am reluctant to use nightly (don’t want to do conditional compilation if not strictly necessary).
So we agree on jswrenn proposition. Then
Try
and all our new fallible iterators (similar to the "adaptors" module/folder).try_collect
for a new maybe_collect
? (It would solve the conflict with nightly.)process_results
for a new maybe_process
(or just maybe
)?_ok
methods for new maybe_
methods?Iterator
(and Itertools
) methods should have a maybe_
variant? Because there is quite a zoo. For now, only the ones having an _ok
variant I guess. We might want to define a clear limit later.FWIW, rayon
also uses a private Try
for its public methods like try_fold
. You're welcome to copy it:
https://github.com/rayon-rs/rayon/blob/5876c80e1208c0aae60092ddfa690a71709e326d/src/iter/mod.rs#L3388
(and rayon
doesn't have the same constraints for wanting to avoid std
method names like Itertools
does.)
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 unstableTry
trait.