37 ms·
Cool. But if you're no_std compatible, please be so by default. It doesn't matter if you're my direct dependency, but it does with transitive dependencies.
by 3836293648 4y ago
Cool. But if you're no_std compatible, please be so by default. It doesn't matter if you're my direct dependency, but it does with transitive dependencies.
- dnedic 4y agoOnly the first layer of the library is no_std compatible, and the server, which most people are arguably looking for is not no_std compatible, hence std feature is enabled by default.
- burntsushi 4y agoThis really depends on what the common use case is. Probably the vast majority of use cases are going to be okay with 'std' and so 'std' should probably be enabled by default. So I wouldn't consider your advice here as good general purpose advice. I agree it can be annoying if you are on 'no_std' and you depend on a library that doesn't expose the 'std' features of its dependencies. Then you're stuck, but I'd consider that a bug of the dependency you're using. Now it is important to make your feature be 'std' as opposed to 'no-std'. That is, features should generally represent additive APIs. This is because you can always enable a feature, but you can't disable one if a dependency has enabled it and hasn't provided a way to turn it off.