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
Is your feature request related to a problem? Please describe.
Currently, our error types do not use external crates, which forces us to implement traits such as Display manually and adds a lot of boilerplate code.
This was unavoidable, as the Error trait that most error handling libraries are based on was part of std up until recently, which prevented using them in no_std environments.
Describe the solution you'd like
As the Error trait will be moved to core with the next stable Rust release (rust-lang/rust#103765) and will therefore be available in no_std environments, we should reconsider the usage of error handling crates in order to remove some boilerplate.
As thiserror is one of the most widely used rust crates for this purpose, it would make sense to use it as soon as it also supports no_std (dtolnay/thiserror#304).
Describe alternatives you've considered
We could also keep the existing code and not switch to thiserror.
This would allow us to keep supporting older Rust versions (using thiserror with no_std would probably require a MSRV bump to 1.81), but we will have to maintain our error types manually.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently, our error types do not use external crates, which forces us to implement traits such as
Display
manually and adds a lot of boilerplate code.This was unavoidable, as the Error trait that most error handling libraries are based on was part of
std
up until recently, which prevented using them inno_std
environments.Describe the solution you'd like
As the
Error
trait will be moved tocore
with the next stable Rust release (rust-lang/rust#103765) and will therefore be available inno_std
environments, we should reconsider the usage of error handling crates in order to remove some boilerplate.As thiserror is one of the most widely used rust crates for this purpose, it would make sense to use it as soon as it also supports
no_std
(dtolnay/thiserror#304).Describe alternatives you've considered
We could also keep the existing code and not switch to thiserror.
This would allow us to keep supporting older Rust versions (using
thiserror
withno_std
would probably require a MSRV bump to 1.81), but we will have to maintain our error types manually.The text was updated successfully, but these errors were encountered: