-
Notifications
You must be signed in to change notification settings - Fork 24
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
Collaborate on a "core::Error" crate with snafu, anyhow and other error crates #24
Comments
The solution to this problem is to make core, alloc and std a single crate, compiled under different feature flags. This refactor is blocked on the fact that it would be infrastructurally complicated to make the change, but it would be very high value to fixing this and several other problems in std's API. I would really love to see someone driving fixing this problem. NB that the parts of fehler that rely on the Error trait could only be no_std + alloc compatible, as they depend on access to heap allocation APIs. |
I agree, and I sort of hope that work on std aware cargo will help towards this goal by simplifying the build system and adding a proper way to build libstd with different features. Unfortunately, I don’t have enough time nor the required knowledge to drive such an initiative right now. Core-error is a much simpler answer to the specific problem of error handling crates that should be fully forward compatible with a unified libstd future.
That’s expected, and totally acceptable. |
I'm going to strip everything that depends on the error trait out of this library, because its duplicating basically exactly the functionality of anyhow (if there are any differences I expect they're my deficiencies). I know dtolnay was +1 on working with you on this, so you can cross den Fehler off your list for potentially incompatible libraries. |
With the recent proliferation of error-handling crates, it has become clear that the situation around the lack of a
core::error::Error
is really suboptimal. Insnafu
,no_std
support is being introduced through a whole new Error trait just forno_std
- which could lead to similar problems thatfailure
had by becoming incompatible with the ecosystem.Ideally, the
Error
trait would show up in core, but due to coherence concerns and std-dependent features being added tostd::error::Error
, a resolution is unlikely to happen soon. As such, I propose making a new crate,core-error
- exposing our own version of theError
trait. The goal of this crate is twofolds:Such a crate would work like this:
std::error::*
no-default-features
, it exposes anError
trait similar to the one instd
but without backtraces, and without the std/alloc-only impls.The trait will be compatible with std's Error trait, and if libcore gains an Error trait in the future, it should be compatible with it too.
Once the crate reaches 1.0.0, I'll consider it ready for integration in the various error crates and will follow the same stability guarantee Rust does: No breaking changes ever.
Work has already started in https://github.com/core-error/core-error. I'd be interested in hearing feedback on the design.
The text was updated successfully, but these errors were encountered: