Kevin Gibbons

> It's also much cleaner to treat iterators as a pure stream of values, not indexed values. You can certainly choose to do that if you want; nothing is forcing...

That is not the definition of "index" I use, but in any case, nothing user-exposed will say this is specifically an "index" rather than a "counter".

> JS has already established the pattern of distinguishing between iterators without indices and iterators of tuples with indices by `Array.prototype.values` vs `Array.prototype.entries` I don't understand how that's an argument...

> It looks like the feedback from https://github.com/tc39/proposal-iterator-helpers/issues/207 is rather against this. I see three people who have expressed opposition (you, `@ljharb`, and `@bergus`), and three who have expressed support...

Observable to whom? The `take` helper knows it's done with the underlying iterator after `n` calls to `next`; that seems the natural time to close it.

`iter` is the thing I'm talking about, yes. To be more precise, I'm talking about when `iter.return()` will get called - is it during the third call to `bounded.next`, at...

I would lean towards wrapping, for consistency. It's weird for the identity to depend on the precise value of an argument like this, and I can imagine code along the...

I think stage 3 warrants at least a sketch of the intended approach. I can try to write something up.

@Jamesernator, you might want to take a look at https://github.com/shapesecurity/shift-spidermonkey-converter-js, which does conversions between a format similar to the one in binast (i.e. shift) and a format similar to the...

@Jamesernator, did you ever end up filing those issues? If you (remember them) and still think they're valid, I'd be interest in reading them.