Why just on iterators and not on arrays?

[ljharb]

I have this need on Arrays just as often as on non-array iterators; any reason not to add it to both?

[michaelficarra]

See the README:

do we support iterators and iterables like Iterator.from and flatMap?

Arrays are iterable, so they would "just work" if we answer "yes" to this question. Also, even if we answer "no", it's pretty easy to turn arrays into iterators with .values() or Iterator.from().

[bakkot]

so they would "just work" if we answer "yes" to this question

Well, you'd get an iterator out rather than an array, presumably? So you'd need to .toArray at the end. Iterator.zip(x, y).toArray() is a bit more awkward than Array.zip(x, y).

[ljharb]

What I mean is, why not have these methods also on Array/Array.prototype?

[michaelficarra]

We could do that, but I think the Array helper is a lot less motivated if we have a good Iterator helper. It's hard and complicated to write your own zip. It's not hard or complicated to write Iterator.zip(a, b).toArray(). And I imagine a good portion of invocations on arrays won't even need to realise an array as the output anyway. new Map(Iterator.zip(keys, values)) or for (let [k, v] of Iterator.zip(keys, values)) ... will work fine for array inputs. For the remainder of cases, calling .toArray() doesn't seem like much of a burden to me.

[ljharb]

Most of my need for zip starts with two arrays and ends with one array, and it seems useful to me to avoid the iterator protocol entirely when it’s not needed.

[tophf]

Having it on Array prototype would probably allow various optimizations in the JS engine, which might be impossible with the generic iterator version.

[michaelficarra]

I wouldn't believe such claims unless they came directly from the implementors. The engines already keep taint bits on things like Symbol.iterator on built-ins and then short-circuit these kinds of operations to optimise when passed arrays or other built-ins. I don't see why they wouldn't do the same here.

[tophf]

I don't see why they wouldn't do the same here.

I thought it's impossible to know beforehand that the developer wants to produce an array in the end so the engine would have to speculate, which is wasteful.

[michaelficarra]

Closing this as we've taken the Iterator.from approach of accepting iterators/iterables, which includes arrays.

[ljharb]

@michaelficarra i don't think that addresses the ergonomics issue nor precludes also adding the method on Arrays.

[michaelficarra]

@ljharb You're right, this proposal does not preclude another proposal that would add a similar static method on Array. I don't think such a method should be included in this proposal, though.

[ljharb]

Why not? This issue shouldn’t be closed until that original question is answered.

[zloirock]

I agree that it should be added to Array too. Extra .toArray() is too ugly for simple cases.