Feature Request: `count_by` under `no_std`

[fxdmhtt]

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.

[hiSandog]

This seems like it would need an explicit feature boundary: no_std + alloc + hashbrown, rather than plain no_std. If the crate already has APIs whose availability depends on allocation, documenting that counts/into_group_map style methods require the same allocation-backed feature would make the tradeoff clear. The main compatibility question is probably whether pulling in hashbrown is acceptable as an optional dependency for users who currently rely on a very small feature set.

[fxdmhtt]

What if, instead of importing hashbrown, we implemented it from scratch using alloc—would that be too much of a hassle?
I feel that limiting it to std would be a loss for itertools.

[phimuemue]

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 foreign HashMap alternative. Plus, users could implement it for their own types.

[fxdmhtt]

I am delighted that you have given this such thorough consideration.

[phimuemue]

Does anybody know if we have precedence for this tactics in our code base?