Add product_ok and sum_ok

[sjackman]

• .try_product() is a more convenient way of writing .product::<Result<_, _>>()
• .try_sum() 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.