Agreed. I’ve been away from Go for a bit - I just assumed with hash/maphash the stdlib had a generic map… ugh.
Rant… this highlights a key problem with Go. Perfect is the enemy of good. Java has had a map interface for 20 years. Millions of successful solutions have been developed. Just use it and move on to more important issues… but instead the Go team will argue over minutia while the code base continues to fragment. Very shortsighted. Go progresses like a code reviewer taking the time to ‘nit’ a PR - you know what - just approve it and take the time to submit your own PR to make those “improvements”. On Jun 26, 2025, at 12:17 AM, Axel Wagner <axel.wagner...@googlemail.com> wrote:
My assumption is that OP wants to de-facto store keys in a map that are not `comparable` (e.g. use a `[]byte` as a key), without having to fully implement their own hash map. Of course, at some point we'll hopefully get #69559 to do this easily. In the meantime, using hash/maphash to calculate a hash and then using that as a key for the built-in map seems like a fair compromise.
but if you have the K to compare to, why not just use map[K]V and let the standard map manage the hash and duplicates - since the OP referred to hash/maphash I assume they are using keys that are comparable
unless the OP is trying to write a complete custom map implementation - but I doubt that is the case if they didn’t understand that hashes can have duplicates
Yes, I meant map[uint64][]struct{K;V}, thanks for correcting me. That is not correct and will not work - what the op is talking about is if K collides - so this is only a single K - so map[K][]struct{K;V} will only ever have one element in the array…
There are ∞ many possible hashable Go values (in particular, all strings) and 2^64 uint64, so yes, there is a possibility of collision. How big that risk is depends on how many values you have and what the damage is, if a collision happens. There, you can see that if you have a 64 bit hash and have, say 190K elements, the probability of a random collision is roughly 10^-9 (so pretty small, but not completely impossible). If a collision is truly problematic, a simple fix would be to use a map[K][]struct{K;V}. That way, if there *is* a collision on the hash, you store all the colliding values and can walk the slice to find the right one. As collisions should be rare, that should be an uncommon cost to pay.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfH6WzHLzoz%3DMe30MamY6th8miTqLFd4_LT_kJ%2BLB2%2B9gg%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfHRHS_5V21MMC6oz5X75k-pXM8hCLN_tCTjfxnG5UEN7g%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/FDCA9F51-9692-425B-B846-D051FCA68403%40ix.netcom.com.
|
