Skip to content
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

Support for no_std with a homespun/third-party Error trait #160

Closed
mzabaluev opened this issue Dec 4, 2021 · 2 comments
Closed

Support for no_std with a homespun/third-party Error trait #160

mzabaluev opened this issue Dec 4, 2021 · 2 comments

Comments

@mzabaluev
Copy link

I'd like to find an alternative to #64 that would not break compatibility for 1.0 users.

How about adding a non-default feature to thiserror that would, instead of std::error::Error, derive an impl of its workalike trait defined in the thiserror library crate, or possibly a reexport of a dusted off and properly released core-error, that would only depend on alloc?

Going further, there could be a feature to select a bare-bones Error trait that would shed downcast and anything else dependent on alloc.

This way, derive(Error) would not be a lie since the macro will derive an Error impl. The users would be free to ignore the impl and only use Display and From if that's what they are after.

@mzabaluev
Copy link
Author

Cc @IcyDefiance @roblabla

@dtolnay
Copy link
Owner

dtolnay commented May 19, 2022

This unfortunately does not sound promising to me, since I think it has most of the same failure modes as the old no_std PR. I'll close the issue but I would love to see a working PR if anyone comes up with some other approach.

@dtolnay dtolnay closed this as completed May 19, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants