Josh Stone

Yeah, I meant the shift by one. Maybe that's self-explanatory, but I'm trying to imagine this from fresh eyes. :)

If we adopt MSRV 1.36 and a new default hasher, I think there will be no more need for `std` at all. But it's not certain that we should do...

I've thought about `Allocator`, but it's difficult to predict when that will even be stable in the standard library. You can't really do anything with that on `Vec` until it's...

Hashbrown's several `RawTable::*insert*` methods works this way, where you're expect to check matches separately first. We do take advantage of that in the `push` being used here, e.g. via `VacantEntry::insert`,...

> Updated the PR with `insert_unique_unchecked` name to match new hashbrown API. > > However, unlike hashbrown, I opted not to return `(&K, &mut V)` from `insert_unique_unchecked` because returning these...

> Simple benchmark of `insert` vs `insert_unique_unchecked` included: > > ``` > test insert ... bench: 14,929 ns/iter (+/- 2,222) > test insert_unique_unchecked ... bench: 11,272 ns/iter (+/- 1,172) >...

@bluss > This is a new feature and in theory we'd bump the version to 1.8 since it's a feature update. I guess it's only debatable where to draw the...

> This does not seem like it is the intended behavior, since e.g. `first_mut` only gives a non-mutable reference to the key. Yeah, `get_index_mut` came long before, but we did...

You could implement a shuffle with a series of [`swap_indices`](https://docs.rs/indexmap/1.6.1/indexmap/map/struct.IndexMap.html#method.swap_indices) -- that's basically how [rand's `shuffle`](https://docs.rs/rand/0.8.3/src/rand/seq/mod.rs.html#586-592) works. If we did this internally, it could be a bit faster because we...

We're happy to match such methods once they're stable, but until then it's subject to change, and we don't want indexmap to get stuck with differences.