Provide stream functions to handle Result streams

[antiguru]

Add a ResultStream trait providing functions modeled after the native
Result type, if their stream counterpart is meaningful. This includes
functions to extract and map Ok or Err variants, as well as
unwrapping, and chaining results with and_then.

Signed-off-by: Moritz Hoffmann [email protected]

[frankmcsherry]

These look good, thanks! Do you have any thoughts about how / whether to blend these with ok_err.rs, which demuxes Result types into two streams?

[antiguru]

We could definitely merge it with ok_err.rs. Let me take a look!

[frankmcsherry]

Scanning, I think the main difference is that ok_err.rs uses a closure to be "broadly applicable" to any timely stream, whereas these methods apply only to streams of results (which makes sense). If we unified them, either might lose part of what makes them nice (ergonomics here, and economy there). Happy to chew on that, or just land this as is. Lmk once you've chewed on it a bit!

[antiguru]

It seems more intuitive to keep ResultStream<S, T, E> instead of moving T and/or E to the functions itself. For this reason, I'm inclined to keep it separate from or_err.rs -- technically we could copy/paste the content in ok_err.rs because it somewhat belongs together. If that's fine with you, feel free to go ahead and merge :)

[frankmcsherry]

Is there a reason that ok() and err() have custom operators, rather than being instances of flat_map()? Just trying to grok the complexity there (and minimize, if possible).

[antiguru]

Yep, good point. Definitely easier to define ok/err in terms of flat_map.

[frankmcsherry]

Looks good; thanks for the PR!

[antiguru]

Thanks a lot! What about pushing a new release to crates?

[frankmcsherry]

That sounds like a responsible thing to do! It's been .. almost a year I think? Maybe more. I'll investigate today!