Clarify stance on no_std
Closed this issue · 2 comments
barafael commented
Currently, this crate is no_std compatible (yay!). However, as of now, one could easily add dependency on std, though it would break the no_std unit test. If you plan to keep this no_std, would you consider adding a #![cfg_attr(not(test), no_std)]
to the crate root?
8573 commented
A no_std
attribute in the crate root of a proc-macro crate is not so useful: a proc-macro always runs with std
available and the attribute does not affect the output of the macro, which is what one would want to keep "no_std compatible".
barafael commented
Thanks :)