Which collection do I choose when [...]

Suppose I do not need a hasher to transform my keys, and all I need to do is map u64's to T's. I was thinking about a no-hasher for the default HashMap implementation, but that seems a bit wanky (defeats the purpose). What would be a good choice in such a scenario?

Are you choosing the u64 key yourself? Then a HashMap<u64, T> should be fine.

If you don't care about the exact key value, do you want the container to manage uniqueness of those Ts? If so, an IndexSet lets you access items by their usize index without further hashing. If not, then just a Vec should do.

1 Like

Does an IndexSet allocate up to the max usize inserted? Because these u64's are network identification values, and as such, are typically very large. Gigabytes of allocation for a singular large entry would be bad.

Not necessarily, but they are being generated by a function of my choosing (randomly generated, ensured to have no collisions beforehand).

IndexSet doesn't let you choose the usize -- it's essentially the index of insertion order. You could also use IndexMap<u64, T> -- then you could use either the usize index for direct access or the u64 key for hashed access.

But it sounds like you really just need to use your u64 key in a normal map, whether that's HashMap, BTreeMap, IndexMap, etc. If the bits of your keys are sufficiently random/distributed, then it seems just fine to use a no-op hasher with this. Why do you hesitate on that?

Actually, off the top of my head I thought this may have existed, but didn't know that was the name for it. Is this included within the std HashMap?

std only has RandomState that builds DefaultHasher.

Someone else asked how to do this a few days ago:

1 Like