Skip to content

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

@mzabaluev

Description

@mzabaluev

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions