What I dislike about *all* the dynamic `Error` strategies is that we can't have something that is both `From<E: Error>` and `impl Error` at the same time. ;__________;
-
-
Replying to @seanmonstar
Could you say more about why you want `impl Error`? I find that `impl From<anyhow::Error> for Box<dyn StdError + Send + Sync>` (zero cost) + `impl Deref<Target = dyn StdError + Send + Sync>` (also zero cost) accomplishes the same thing seamlessly in 100% of places I know of.
2 replies 0 retweets 2 likes -
Replying to @davidtolnay
I've had methods and enum variants with `E: Error` bounds that blew up when I changed one of my error types to `Box<dyn Error>`.
1 reply 0 retweets 0 likes -
Replying to @seanmonstar @davidtolnay
Instead of `where S::Error: Error`, it's become `where S::Error: Into<Box<dyn Error>>` everywhere, which is not as clear IMO.
1 reply 0 retweets 0 likes -
Replying to @seanmonstar
Ah good call. I have some `type Error: StdError` associated types in Serde's traits that in hindsight should have been `type Error: Display + Debug` only. I would be curious to see an example of a function that really needs StdError bound on a generic parameter if you have one.
1 reply 0 retweets 0 likes
True, I originally reached for `E: Error` as it's shorter. But it also allows propagating the source chains, whereas just `E: Display` would not.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.