It has no breaking changes

Unfortunately, this is a breaking change, for two reasons:

1. Features must be additive, in that enabling a feature must not constitute a breaking change. Consider if two crates in a dependency both need indexmap, but one asks for no-default-features (for no_std) and the other uses the default with "std". In this case, changing the "std" feature entirely changes the RandomState type used for the default S parameter, which could break the one that didn't ask for "std".

   • We could work around this by not providing a default S at all for no_std, which also requires gating the new and with_capacity methods.

2. Someone could already be depending on indexmap with no-default-features, expecting this to work with std, not needing the newly-stabilized alloc. So restricting the current std functionality to a new feature flag also constitutes a breaking change, even if it's a default!

   • I ran into this when I tried to implement no_std for the num crates -- see Yank num 0.1.38 rust-num/num#297. The eventual solution was to do this in a new semver version, but then use the semver trick to have the old version re-export everything from the new with "std" enabled.
   • So we could release indexmap 2.0 where "std" is a default feature, and then a new indexmap 1.0.z which re-export the std-enabled items from 2.0.

So there are problems here, but I think they can be solved. It's a little annoying to need 2.0 though -- do you have a motivating use case for this? If it's just "because we can", I'd say we shouldn't bother...

It may be cleaner to replace uses of std with core or alloc, rather than creating a fake std. Please let me know if you'd prefer that.

Yeah, style-wise I'd prefer to use core directly, and only use cfg alloc for Vec and Box as needed.

Someone could already be depending on indexmap with no-default-features, expecting this to work with std, not needing the newly-stabilized alloc.

IMHO we don't need to care about this. Because this crate has no default features to start with, we should not let ourselves be held hostage by those that configure like this. I.e default-features=false has been a working but meaningless configuration until we go live with some default feature.

Well FWIW, I got called out on default-features for num: rust-num/num#297

You could choose to write off such users, but #95 shows how to do it without features.

Ok! I agree, #95 seems good and you've taken it in the right direction for sure. I just didn't understand the build script stuff (because it was not complete).