Rfcs: `len()` should be a member of a trait applied uniformly to all collections

[solidsnack]

All the collections do seem to have a .len(&self) -> usize but it is not a member of a trait so there is no way to determine the length of an arbitrary "finite collection".

[nagisa]

There is: https://doc.rust-lang.org/stable/std/iter/trait.ExactSizeIterator.html

[solidsnack]

This suggests one can get the length of a BTreeMap with the_map.into_iter().len(). However it does seem strange that BTreeMap has its own .len() and .is_empty(). It seems reasonable that every collection that can be converted to an ExactSizeIterator could itself implement the trait (although it would then be a funny name).

[Stebalien]

We're waiting on some form of HKT before we start on collection traits (we need it to express, e.g., Collection::iter()).

[solidsnack]

Ah, okay.

Should I close this one? Is there something tracking it?

[Stebalien]

Should I close this one?

Probably. If you want you could open a collections traits issue to cover the more general problem.

Is there something tracking it?

I don't know of any specific issues tracking collections traits.

---

You might consider following the HKT (#324) issue and this discussion (and the related blog posts).

If you're interested in collection traits in general, you might also want to read (slightly outdated):

• Libcollections traits: a standard interface for all collections
• Collection Traits, Take 2

(/cc @Gankro)

[tterribe]

I came here to file this exact issue. HKT doesn't seem to have had much movement lately. Perhaps there is room to make incremental progress on collection traits with things like this?

[drdozer]

Hi - I found this googling for the exact same abstraction. I don't think this is actually blocked by HKT imho, since there's no higher-kinded result type in play. len and is_empty don't refer to the element type, or to the collection type abstracted over the element.