I also looked at autocfg to figure out how to test this. ⚙️

I have a worry that other "no_std" using crates are going to be disappointed in this (3) scheme, when they can't test this with crate features as we normally do.

I still lean towards this being the morally right way to handle no_std; we build without it because it is not available.

I'm looking for a simpler no-std hasher than ahash (since it depends on a lot of stuff).

The main hazard I see in leaving this implicit is that users could end up depending on std-required API (like IndexMap::new) without realizing it. I guess it's up to them to try a true no_std target if they really need that. Plus this kind of failure can also happen with unified features -- if something else in your dependency tree enables a feature, you can also use it without declaring so.

But I am in the camp that losing std with default-features = false is a breaking change, so this auto-detection is really the only way around that.

I'm looking for a simpler no-std hasher than ahash (since it depends on a lot of stuff).

Maybe twox-hash? Or since it's just for testing, you could add a private copy of fnv / fxhash.

Thanks for implementing @leo60228 and thanks @cuviper for guiding the implementation.

I'll aim to release this in Indexmap 1.3 since it's a new feature