Skip to content

Conversation

aqrln
Copy link

@aqrln aqrln commented Aug 13, 2025

Add an optional hashbrown feature that switches the underlying hash map implementation from std::collections to hashbrown and makes items that depend on hash maps available without use_std (although it still requires and implicitly enables use_alloc).

This addresses the motivating use case of #605 (which is the same use case that I am interested in) but does not implement a generic approach as the issue suggests. #901 would be a better solution long term and would make these changes obsolete, but the PR appears to be stalled and I wanted a simple solution that allows using APIs like unique/unique_by with no_std now.

It also partially addresses #322 because enabling this feature does switch to a faster hash algorithm, it just doesn't allow to specify which one exactly (currently the default hasher in hashbrown is foldhash, so this is what's going to be used until/unless changed upstream in the future).


TODO:

  • fix tests compilation with --all-features/-F hashbrown
  • run tests on CI with both hash map implementations
  • adjust contributor doc in the section about use_std

I'm opening a draft PR early because I'd like to get feedback on whether it's something you want to have.

Add an optional `hashbrown` feature that switches the underlying hash
map implementation from `std::collections` to `hashbrown` and makes
items that depend on hash maps available without `use_std` (although it
still requires and implicitly enables `use_alloc`).

This addresses the motivating use case of [rust-itertools#605][] (which is the same
use case that I am interested in) but does not implement a generic
approach as the issue suggests. [rust-itertools#901][] would be a better solution long
term and would make these changes obsolete, but the PR appears to be
stalled and I wanted a simple solution that allows using APIs like
`unique`/`unique_by` with `no_std` now.

It also partially addresses [rust-itertools#322][] because enabling this feature does
switch to *a* faster hash algorithm, it just doesn't allow to specify
which one exactly (currently the default hasher in `hashbrown` is
`foldhash`, so this is what's going to be used until/unless changed
upstream in the future).

[rust-itertools#605]: rust-itertools#605
[rust-itertools#901]: rust-itertools#901
[rust-itertools#322]: rust-itertools#322
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant