Iterator combinator methods

# Benjamin Gruenbaum (7 years ago)

Hey,

I remember a lot of talk about adding .map/.filter etc to iterators. The benefits of doing this are pretty big and I think fairly well understood and several other proposals (like observables and async iterators) would benefit from it.

(I expand on the big advantages this has over Array#map/filter if needed).

Is anyone currently working on such a proposal? Was it discussed?

I'd really like to see it move forward.

Cheers

# Dmitry Soshnikov (7 years ago)

There are some good examples with MapIterator, and its filter, map, collect or collectAs final methods here (from some old discussion): rwaldron/tc39-notes/blob/master/es6/2014-11/nov-19.md#58-mapprototypemap-and-mapprototypefilter-spec--set I'm pretty sure there should've been other discussions on this, but I'm not sure about current state.

Just build a working prototype library from those examples as a proof on concept. Then spec'ing it should be relatively easy after it (assuming a champion who will be willing to run it through).

Dmitry

# Isiah Meadows (7 years ago)

Shouldn't those be implemented in %IteratorPrototype% instead, so they can be used across all iterator types (including array entries, set entries, generator instances, etc.)?

# Reinis Ivanovs (7 years ago)

It's a complex issue:

  • Should the methods be lazy or eager? Not making them lazy would be a missed opportunity
  • How is conversion between iterators/iterables handled? Something like @@species for Array, or leave it to users to convert manually?
  • Should it be prototype methods or actually generic methods to be used with bind syntax if that makes it into the language? As in, something like const {map} = Iterator; [1,2,3]::map(x => x + 2)