-
-
Notifications
You must be signed in to change notification settings - Fork 147
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
Would this be worth exploring adding to std? #13
Comments
I am open to that, but since this crate just came out yesterday it's a bit early to say. I think if we still think this is the best possible approach after ~12 months then that could be good justification for a std::error RFC. |
Bumping as it's been 14 months (making "later" now) since the above comment. I do feel like this is the best possible approach to Rust error handling. How should exploring adding to std proceed if it is still viable? |
RFC 2820 has some discussion on a standard type erased error type. There is also now an error handling project group (https://github.com/rust-lang/project-error-handling) whose purview such a proposal would be under. |
The error handling project group clearly knows about this crate, so I don't think I need to keep this issue around. Closing and will leave it to them as far as what goes in std. |
First, this crate is awesome. I feel like Rust's error story is starting to feel really ergonomic.
This crate looks like a very nice Error type to reach for when working with a leaf/application crate.
Have you thought about working towards adding it to
std
?anyhow::Error
could be added asstd::error
( as a pseudo-primitive ) via the same hack thati32
andstd::i32
are mergedstd::error
could be a very good default for variousErr
,Error
, andE
type parametersstd::error
in a future edition could be added to the prelude as justerror
The text was updated successfully, but these errors were encountered: