Repository navigation
Feature Request: count_by under no_std #1092
Description
Thanks to the existence of the hashbrown crate, it is possible to provide no_std support for HashMap—provided that alloc is enabled.
The code itself remains unchanged; only the import statements need to be modified.
use core::hash::Hash;
use hashbrown::HashMap;
pub trait Counts: Iterator {
fn counts(self) -> HashMap<Self::Item, usize>
where
Self: Sized,
Self::Item: Eq + Hash,
{
let mut counts = HashMap::new();
self.for_each(|item| *counts.entry(item).or_default() += 1);
counts
}
}
impl<I: Iterator> Counts for I {}Would you consider adding this support? Doing so would broaden the applicability of the APIs related to HashMap and HashSet.
Activity
hiSandog commentedon Jun 30, 2026
This seems like it would need an explicit feature boundary:
no_std + alloc + hashbrown, rather than plainno_std. If the crate already has APIs whose availability depends on allocation, documenting thatcounts/into_group_mapstyle methods require the same allocation-backed feature would make the tradeoff clear. The main compatibility question is probably whether pulling inhashbrownis acceptable as an optional dependency for users who currently rely on a very small feature set.fxdmhtt commentedon Jun 30, 2026
What if, instead of importing
hashbrown, we implemented it from scratch usingalloc—would that be too much of a hassle?I feel that limiting it to
stdwould be a loss foritertools.phimuemue commentedon Jun 30, 2026
We could introduce our own trait that offers precisely what we need for our methods. Then, we could implement it for
std::collections::HashMap, and - under feature flags - implement it for widely used foreignHashMapalternative. Plus, users could implement it for their own types.fxdmhtt commentedon Jun 30, 2026
I am delighted that you have given this such thorough consideration.
phimuemue commentedon Jun 30, 2026
Does anybody know if we have precedence for this tactics in our code base?