Detecting std or no-std instead of using a crate feature

Hi everyone,

I'm looking for review of this approach to no_std. This is a crate that will always require alloc, but it can be no_std otherwise with little loss of features.

In brief, the proposal is that no_std is triggered by feature detection picking up that std is not available. It is not triggered by a crate feature flag (or rather the lack of one), as is common elsewhere.

Thoughts and constructive criticism on this approach? See the .traivis.yml file for how this is tested, by building on a target which doesn't have std.

1 Like

One downside is that it makes it easier for downstream libraries to accidentally depend on the APIs that std-detection enables, as they may not be explicitly testing on a std-less target.

With this level of testing (that I do too), it's already too easy to accidentally include std-using components that come from overlooked dependencies and so on. In that sense, it seems like if we had universal feature detection (or cfg from rustc built in), we would be more likely to do this correctly already?

It sounds like this is the sort of problem that would be solved by the Portability Lint RFC.

Indexmap 1.3 is now live with this feature, that it auto-detects missing std.

1 Like