-
Notifications
You must be signed in to change notification settings - Fork 36
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
Crate isn't really no-std compatible #47
Comments
I am by no means an expert in the no-std field and the PR seemed to satisfy the person that wanted to use the crate in a no_std environment
Is this no longer true? If it isn't it changes the trade-offs. If it is still true I don't see the point you are trying to make here:
The stacktrace is a very valuable source of information if anything goes wrong and I have to debug it. I guess not having a stacktrace in no_std is fine, but completly ditching it seems weird to me, but it is maybe be worth it? Would you have a suggestion for a better crate to make display messages as easy to create as with thiserror that is no_std compatible? |
I think that since rust-lang/rust#66741 it is possible to create no-std binaries. This issue was the last blocker if I'm not mistaken.
I don't care so much about which error crate is used, but I'm personally using
Is it actually? If you have several different places return the same error enum variant then a stack trace can help you know which of these places has actually triggered it. However, while I don't know the source code of Providing some context to the error (e.g. the values of the inputs) is generally very valuable, but that's not something that the |
Does that not involve building a binary just in the static_lib/dylib format? Again I am not very familiar with the whole no_std environment. I'd imagine, that this involves the same restrictions as "normal" no_std compilation, right? |
I think #48 resolves this by lifting the nightly requirement. |
Started work on this branch. Looks promising. https://github.com/KillingSpark/zstd-rs/tree/remove_thiserror |
Nice. Sent #49 to address existing lint errors. |
You might also be able to do something like |
Thank you 🙏 |
#39 supposedly added support for no-std.
However I strongly disagree with this point:
You can't really consider a crate to be "no-std compatible" if it requires nightly.
And let's face it: at the rhythm where it's going (the first attempts at moving this trait were in 2021), it's going to take a very long time for
core::error::Error
to be stabilized.My suggestion would be to not derive the
Error
trait at all, but onlyDebug
andDisplay
and possibleClone
. This can be done by ditching thethiserror
crate and using a different one.After all, the
Error
trait isn't very useful. All it does is potentially provide a stack trace. It's not because it's named "error" that types that represent errors always have to derive it.The text was updated successfully, but these errors were encountered: