[sjackman]

• .product_ok() is a more convenient way of writing .product::<Result<_, _>>()
• .sum_ok() is a more convenient way of writing .sum::<Result<_, _>>()

Modelled after .try_collect()

[Philippe-Cholet]

We have a bunch of methods about iterators of results: map_ok filter_ok filter_map_ok flatten_ok fold_ok (and related but different process_results) and try_collect clashing with the nightly Iterator::try_collect.

I think try_ methods should be reserved to (unstable for now) Try trait usages.
For consistency, I would suggest names to be product_ok and sum_ok.

Now, do we want to add those shortcuts? That's the question. @jswrenn What do you think?

EDIT: The documentation of sum (same for product) mention panics. It would do the same here.

Panics

When calling sum() and a primitive integer type is being returned, this method will panic if the computation overflows and debug assertions are enabled.

I failed to read the documentation once but if this is not mentioned then someone will have a problem.

[sjackman]

For consistency, I would suggest names to be product_ok and sum_ok.

Done!

[sjackman]

EDIT: The documentation of sum (same for product) mention panics. It would do the same here.

Done!

[Philippe-Cholet]

@jswrenn Merry Xmas. What do you think about adding product_ok and sum_ok?
(There is also #830 about a fold_while_ok?)

[jswrenn]

Hm, this is an inelegantly large number of generic arguments.

This is a fairly radical alternative, but: What if we just mirrored the stdlib Try trait? We can pub-in-priv our Try-fork so that folks don't end up explicitly depending on it, and then simply (and potentially non-breaking-ly!) switch over to the standard library Try once it's stabilized.

If we do this, our *_ok functions will support more than just Results, and they'll be able to take just one generic argument, rather than three (I think).

Thoughts, @Philippe-Cholet and @phimuemue?

[jswrenn]

Something like this: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=7b632d50ccce769af18ec8985ff45359

[Philippe-Cholet]

That sure is radical but interesting, maybe it should have its own issue.
About the names, *_ok now and try_* later? (or maybe_*?!)

After a quick look, ControlFlow requires 1.55+ while we currently have 1.43. Unless we copy it too?
I previously read something about #[track_caller] but don't remember much about its use.

In libcore, fold is usually specialized using try_fold specializations alongside with NeverShortCircuit which surely won't be public forever so I thought that we would copy it at some point.

[sjackman]

@Philippe-Cholet @jswrenn Any thoughts on merging this PR to add sum_ok() and product_ok()?

[phimuemue]

Hi there @sjackman, thanks for bringing this up, and sorry for taking so long.

We (more or less) established the guideline to avoid these "convenience methods" (there are several other similar PRs that we did not merge). Following that, I'll close this PR.