1 of 9

Iterator Methods

Update + Stage 2

2 of 9

Refresher

3 of 9

Refresher

4 of 9

Refresher

5 of 9

What we have now

map
filter
take
drop
asIndexedPairs*
reduce
collect
forEach
some
every
find

Array methods
Bounding infinite iterators
Array <-> Iterator

6 of 9

asIndexedPairs naming

Known as enumerate in most iteration APIs
Introduces a counter from the point it is called
Name bikeshedding

enumerate, withIndex, asIndexedPairs, toIndexedPairs, etc

An operation over an iterator at any given point is not bounded to a specific index. (The data might have come from an array but the filterer doesn’t know that).

A very important design choice made in other languages was to not have counters implicitly available within the context of iteration. Instead, the `enumerate` method is added which explicitly adds a counter from the point it is called.

Example: Because there is an implicit counter in this theoretical map, a bug is introduced when the developer wants to trim the incoming data.

We can avoid this problem entirely by not having an implicit counter at all, and instead forcing the developer to introduce this state in the first place.

We need to decide on a name. I would like to move forward with `enumerate` but there was concern that the name wasn’t clear enough. Other languages use `enuemerate`.

7 of 9

Design FAQ

Why on iterator instead of iterable

Iterators are already their own interface with a prototype we can add methods to
Calling a generator (syntactic iteration primitive) returns an iterator
array.forEach, map.forEach, etc already taken

Why methods instead of functional application

Consistent design with JS in general, and the JS list primitive (array)

thisArg

Common case is arrow functions
it.map(f.bind(thisArg)) is more explicit than it.map(f, thisArg)

8 of 9

How to specify async generators

9 of 9

Stage 2?