idanarye/rust-typed-builder

Clarify stance on no_std

Closed this issue · 2 comments

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".

Thanks :)