Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide stream functions to handle Result streams #348

Merged
merged 2 commits into from
Dec 29, 2020

Conversation

antiguru
Copy link
Member

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 antiguru@gmail.com

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 <antiguru@gmail.com>
@frankmcsherry
Copy link
Member

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
Copy link
Member Author

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

@frankmcsherry
Copy link
Member

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
Copy link
Member Author

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
Copy link
Member

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).

Signed-off-by: Moritz Hoffmann <antiguru@gmail.com>
@antiguru
Copy link
Member Author

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

@frankmcsherry
Copy link
Member

Looks good; thanks for the PR!

@frankmcsherry frankmcsherry merged commit f0206b9 into TimelyDataflow:master Dec 29, 2020
@antiguru antiguru deleted the result_support branch December 29, 2020 11:37
@antiguru
Copy link
Member Author

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

@frankmcsherry
Copy link
Member

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

@github-actions github-actions bot mentioned this pull request Oct 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants