Crates should consider supporting no_std if reasonable

[ExpHP]

Crates that have signatures and/or trait impls for std types cannot backwards-compatibly add a std feature (because downstream crates may be using default-features = false). Therefore, this is something a crate should add before 1.0, not after.

[dwijnand]

What's a good (nice and simple) example of doing this right?

[dwijnand]

(Also default-features = false is related to rust-lang/cargo#3126)

[BurntSushi]

@dwijnand The regex crate does this, without actually supporting no_std or alloc-only use cases yet.

The features are defined here: https://github.com/rust-lang/regex/blob/60d087a23025e045ae754a345b04003c31d83d93/Cargo.toml#L47-L54

And a convenient compilation error is defined here: https://github.com/rust-lang/regex/blob/60d087a23025e045ae754a345b04003c31d83d93/src/lib.rs#L524-L525

Note that you should use std instead of use_std for the feature. That was a gaffe on my part.

[KodrAus]

One possible gotcha when adding conditional std support is error handling when we don't have the std::error::Error trait available. This is something I've run into with serde, where additional trait bounds on std::error::Error are added to its API based on the presence of the std feature so it's possible for your library that implements the no-std versions of the traits to just stop compiling depending on who else pulls in serde.

I think that's just an example of a broader recommendation that Cargo features should not change the public API in breaking ways, but since std::error::Error is ubiquitous and absent from no-std I think it deserves a callout.