In this section of The Cargo Book, it says that: A consequence of this is that features should be *additive* .

It gives an example of no_std:

"
For example, if you want to optionally support no_std environments, do not use a no_std feature. Instead, use a std feature that enables std .
"

While I understand the intention, I'm wondering if that's always the best choice in practice.

Using the same example, if a library foo is used in std environment for 90% cases, and also supports no_std for the rest 10% cases, I feel that having a feature of no_std is more intuitive, simpler for most users especially if the user has default-features = false.

I think there is a kind of “natural expectation” that a feature represents something special or optional rather than the most common configuration. In this example, I feel defining std as a feature goes against such intuition.

What do you think?

5 posts - 4 participants

Read full topic