You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 anError impl. The users would be free to ignore the impl and only use Display and From if that's what they are after.
The text was updated successfully, but these errors were encountered:
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.
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 ofstd::error::Error
, derive an impl of its workalike trait defined in thethiserror
library crate, or possibly a reexport of a dusted off and properly releasedcore-error
, that would only depend onalloc
?Going further, there could be a feature to select a bare-bones
Error
trait that would sheddowncast
and anything else dependent onalloc
.This way,
derive(Error)
would not be a lie since the macro will derive anError
impl. The users would be free to ignore the impl and only useDisplay
andFrom
if that's what they are after.The text was updated successfully, but these errors were encountered: