Add support for custom hashers#51
Conversation
|
Thanks for the contribution! It's likely to be a few days before I can properly review this--life is hectic right now--but I have seen it, and it's on my task queue. |
|
I'm installing off my fork for the time being so no rush on my end :) |
|
Good news! I'm finally back and able to review this, after "a few days" somehow turned into half a year. Bad news: I made some changes, not to this pr. I think they'll make the PR cleaner, but it means there are now some merge conflicts. Can't expect better behavior from anyone else than I can of myself. So! Let's get this fixed up and merged by 2026! |
Adds a third generic parameter S (defaulting to RandomState) to Counter, allowing users to specify custom hash builders for the underlying HashMap. This enables use cases like deterministic hashing or performance optimizations. Key changes: - Add generic parameter S = RandomState to Counter struct - Update all trait implementations to include the S parameter - Add BuildHasher bounds only where HashMap operations require them - Add Default bounds only for constructors - Include test demonstrating custom hasher usage Closes coriolinus#32
mjclarke94
force-pushed
the
custom-hasher
branch
from
9ce9e17 to
99ff5c3
Compare
|
I'll stretch for winter 2025 just so it's ready for the next advent of code! Should merge cleanly now |
coriolinus
left a comment
coriolinus
left a comment
There was a problem hiding this comment.
Thanks for the patience, and for this work!
|
Looks like this broke the build with |
3 participants
Attempts to close #32. Still needs documentation etc, but figured I'd get the initial PR up for code review.
I'm fairly new to rust so feel free to be brutal here! It's likely that I'm missing something obvious here.
I was looking into whether it would be plausible to also be generic over the map type (say, to allow
BTreeMapinstead ofHashMapwhich might be handy when it comes to things likek_most_common, but was struggling to see how to make it be generic over both.