Josh Stone

At a high level, I don't want to lock an external crate dependency in our public API, especially pre-1.0. That is, `hashbrown`'s default is just an alias for `ahash::RandomState` (0.7),...

> The good thing about this PR's current changeset is that it's not a breaking change, as it only offers a default type parameter that can still be customized (as...

> @cuviper can't it still be a problem if a crate is written using indexmap and nostd, and then it has its environment shifted by someone depending on that crate...

FYI, the master branch is now on `2.0.0-pre`, so this is the time to make any changes. I already moved to explicit `"std"` only, but otherwise the default `S` is...

I think we'll still run into the fundamental issue, that a feature ("std") should not **change** the meaning of a type like `IndexMap`, with its hidden/default `S`. That said, I'll...

Binary search is O(log n), but inserting at an arbitrary index is still O(n), both for the internal `Vec::insert` and for all the index updates in the raw hash table.

This is an artifact of `hashbrown::raw::RawTable`, and you can reproduce it with `std::collections::HashMap` too, just removing by key instead of index. Capacity is reported as `items + growth_left`, but the...

> Why does `DELETED` not change `growth_left`? I think it's because those `DELETED` entries are considered part of the load factor of the map, affecting how far you might have...

Currently, the only guarantee about avoiding allocation is if you dynamically check the `capacity()`. With hashbrown 0.11 (#181) we could add a method that internally uses `RawTable::try_insert_no_grow`, and on failure...

Hashbrown's [`capacity`](https://docs.rs/hashbrown/0.11.2/hashbrown/struct.HashMap.html#method.capacity) says this: > This number is a lower bound; the `HashMap` might be able to hold more, but is guaranteed to be able to hold at least this...