proposal: either support arbitrary iterables in std/collections or split into std/array / std/record(?)

[Jessidhia]

std/collections has a very... ambitious name for the kind of things it can operate on: either native arrays or property bag objects ("Record" in TypeScript parlance); I actually found this genuinely a bit surprising while browsing the API.

It should be possible to get support for any non-Array @@iterator (such as TypedArray, NodeList, HTMLCollection, Set, generator call result, etc) for free on functions that don't do random access by operating on Iterable<T> instead of readonly T[] arguments.

Similarly, the functions that operate on records can also support Map (and URLSearchParams, and other Map-likes) by accepting an Iterable<[K, T]> / Iterable<[K, Iterable<T>]> / etc, and using Object.entries to convert non-iterable records to an iterable version.

---

If this is genuinely beyond the scope of what you want in a module named @std/collections, then perhaps it should be split/renamed to something more specific, or alternatively specialized implementations that don't go through the iterator protocol could, e.g., be published in an @std/array

[Jessidhia]

(Embarrassingly, it turns out I just happened to only have clicked on the exports that did not support Iterables like chunk, takeWhile, unzip; another handful of the exports do support Iterables, so I suppose this is already in progress?)

[kt3k]

Yes, we've been gradually adding support of iterables where they make sense (such as #3390 ). PRs are welcome if you find more places suitable for supporting it.

[iuioiua]

Can we open a tracking issue for the remaining work?