Non-existent adoption/usage in the wild

[pemrouz]

Whilst I think there is some value in doing this, it's a little bit concerning that usage of this approach of having transforms as iterators is effectively zero (itertools). To quote @domenic, do we need to get high adoption first? If not, at least explore/reflect on why the wider community has explored and decided not to take this approach?:

I think a crucial part of getting stage 2 (i.e., commitment that this should be in the language) is signs that this method gets high adoption, comparable to existing libraries, and that TC39 isn't pushing through something that the community is uninterested in. So I think it should be released during stage 1, and high adoption for the library will be a stage 2 prerequisite.

[domenic]

I think https://www.npmjs.com/package/lodash is pretty good evidence that the community is interested. (There, you do _(iterator).map(...) instead of iterator.map(...), because lodash wisely chose not to monkeypatch the built-in Iterator.prototype. But the idea is the same.)

[pemrouz]

That's a very vague connection. Being realistic and quantifying the overlap, this proposal doesn't cover 1% or 0.1% of the functionality of lodash. Even looking at the documentation for map, it doesn't cover a fraction of the same use cases. It also isn't designed around iterators. As debated in #8, lodash works on iterables - and even more powerfully non-iterables (object-to-object transformations). This proposal isn't to standardise lodash or able to effectively replace it to claim it as relevant prior art.

[ExE-Boss]

Java has this since version 8 in the form of streams.