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

Stream & Sink Error types could benefit from core::fmt::Debug bound #2857

Open
bionicles opened this issue May 11, 2024 · 1 comment
Open

Comments

@bionicles
Copy link

I find one quanta of friction making it a bit harder to work with generic streams & sinks is they have this associated error type which is usually awesome because you control the error type, but in the case of streams and sinks, the low level details are really hard, so it's much more likely for a wide variety of developers to wind up using a smaller number of streams and sinks at a high level. Anyway, since more people are using streams and sinks than developing new streams and sinks, that means all the users are stuck with the trait bound on type Error, which doesn't exist,

Problem is, type Error doesn't have any trait bounds, it could be anything; this means it's hard to functionally map the Err branches because we need a custom error handler for each kind of Stream and Sink, you can't debug print your errors from Streams / Sinks, you're screwed, can't turn it into anyhow::Error because it's not a std::error::Error.

One wonders how much of a breaking change it would be for Stream and Sink Error to both be bounded by "std::error::Error" ? big issue is this weirdly breaks with anyhow because they didnt implement std::error::Error for anyhow::Error, a decision which makes no sense except as a hack to avoid From conflicts. Therefore, I meekly suggest we need an easier bound for Stream / Sink errors than std::error::Error, but more than no bound..

A type Error: core::fmt::Debug bound would at least let us print out the errors regardless of the stream/sink we're dealing with. That'd be the minimalist approach and would work for anyhow::Error as well as custom or default error types. I just think it's important to have a fully functional interface because otherwise we have to re-implement differently for each kind of stream (source) and sink

LMK what you think, it's probably going to break stuff, but at least this way we could always generically debug print our error messages in streaming programs. Thank You!

@bionicles bionicles changed the title Stream & Sink Error types do not impl std::error::Error Stream & Sink Error types could benefit from core::fmt::Debug bound May 11, 2024
@bionicles
Copy link
Author

bionicles commented May 11, 2024

example of the problem:

        match sink.send(output).await {
            Err(e) => Err(anyhow!("unprintable error from the outpipe sink  {e:#?}")),

you'd need to repeatedly qualify your functions only work

where <S2 as futures::Sink<O>>::Error: std::fmt::Debug
error[E0277]: `<S2 as futures::Sink<O>>::Error` doesn't implement `std::fmt::Debug`
   --> src/flow.rs:148:76
    |
148 |             Err(e) => Err(anyhow!("unprintable error from the outpipe sink {e:#?}")),
    |                                                                            ^^^^^^ `<S2 as futures::Sink<O>>::Error` cannot be formatted using `{:?}` because it doesn't implement `std::fmt::Debug`
    |
    = help: the trait `std::fmt::Debug` is not implemented for `<S2 as futures::Sink<O>>::Error`
    = note: this error originates in the macro `$crate::__private::format_args` which comes from the expansion of the macro `anyhow` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider further restricting the associated type
    |
144 |     async fn load(&mut self, output: O) -> anyhow::Result<()> where <S2 as futures::Sink<O>>::Error: std::fmt::Debug {
    |                                                               ++++++++++++++++++++++++++++++++++++++++++++++++++++++

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

No branches or pull requests

1 participant