The way features work in cargo is that each crate in the dependency graph is built a single time with the union of all requested features from each dependent crate. For this reason, enabling a feature should never remove items or change a function's signature; they must only add items.
As an example of how the current setup can go wrong: Suppose a library depends on faster and enables the no-std feature because it doesn't needstd, while another crate enables no features and uses the SIMD iterator impls for Vec. If an application depends on both of them, faster gets compiled with no-std, and the second crate will fail to compile.
The recommendation is to have a std feature that is enabled by default:
[features]
default = ["std"]
std = []
(note: the specific name "std" is recommended by the Rust API Guidelines (see C-FEATURE))
The way features work in
cargois that each crate in the dependency graph is built a single time with the union of all requested features from each dependent crate. For this reason, enabling a feature should never remove items or change a function's signature; they must only add items.As an example of how the current setup can go wrong: Suppose a library depends on
fasterand enables theno-stdfeature because it doesn't needstd, while another crate enables no features and uses the SIMD iterator impls forVec. If an application depends on both of them,fastergets compiled withno-std, and the second crate will fail to compile.The recommendation is to have a
stdfeature that is enabled by default:(note: the specific name
"std"is recommended by the Rust API Guidelines (see C-FEATURE))