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. ;__________;
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.
-
-
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>`.
-
Instead of `where S::Error: Error`, it's become `where S::Error: Into<Box<dyn Error>>` everywhere, which is not as clear IMO.
- 2 more replies
New conversation -
-
-
The former makes `?` work for interop with functions that return `Result<T, Box<dyn StdError>>`. The latter makes anyhow::Error work as a #[source] e.g. within `thiserror`'s derive(Error).
-
Neither of those actually require a StdError impl for anyhow::Error, though it's common for people to assume they would.
End of conversation
New conversation -
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.