Is this project still active?

[pranav-bhatt]

This seems just like what I need to make my project no_std compatible!

[roblabla]

This crate was never properly published to start with haha. I never got around to publishing it, mostly because I'm not working on nostd projects much anymore, and I had kinda forgotten about it.

The last remaining challenge I had before feeling confident enough to release a 1.0.0 version was to add more documentation about what this crate is and how to use it, and figure out how to handle cargo features.

core-error currently has two features: alloc and std. std turns this crate into a dumb facade for re-exporting libstd's Error, alloc implements Error for the error types that live in liballoc and adds downcasting features to error crate.

Those features are disabled by default. The rationale is that it's very easy to break no-std compatibility due to pulling a dependency in your dependency graph that accidentally enables the std features. This is further complicated by cargo unifying the features in build/dev/proc-macro dependencies. This means that if a build dependency enables the std feature (rightfully - proc macros will always have libstd), it will also enable it for your no-std crate, breaking no-std compat. So to minimize this problem, we disable the features, and instruct users to let the "top-level crate" enable the features or not.

Cargo is actually making progress fixing the feature unification issue, see https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#features. This wasn't available when I last worked on core-error, and is a big game-changer that makes me a bit more confident that this approach works and is future-proof.

So the last remaining thing at this point is adding docs explaining what this crate is about to the crate-level docs (e.g. expand this a bit) and I can then release a 1.0.0. 1.0.0 is just the start though - after this we'll need to integrate it into the various error handling crates like snafu, thiserror, etc... and submit PRs to the long, long trail of crates that directly implement error.

[pranav-bhatt]

I was actually reading your comment that you left a while back about getting this integrated. Libs like SNAFU already have their own implementation, so do you thing it'll be integrated any time soon?

[shepmaster]

There's also been some progress (ish) Rust-side: rust-lang/project-error-handling#11

[Manishearth]

This is further complicated by cargo unifying the features in build/dev/proc-macro dependencies.

Note that this is fixed with the new resolver.

---

Would it still be possible to do a 1.0 or even a 0.1? For my no_std use case I really just need this trait, nothing special. I might also get by by creating a different trait that is blanket-impld on Debug + Display