iterators are for very large things, arrays are not

[michaelficarra]

When talking to @rbuckton about this proposal, he brought up that, even if we had this and you passed some very large array, it's still going to have terrible performance because it will iterate the entire thing using the iteration protocol. And sure, we could special-case arrays, or more generally optimise the iteration protocol for arrays, but I think that's a band-aid. Iterator.concat is a constant-time operation. I would think that most of the times that people run into this issue, they would be better served by switching to use iterators instead. Maybe it's not a bad thing that this fails? Is there a case where people are working with such large data and still need array-like behaviour such as constant-time indexing or length checking?

[jridgewell]

it's still going to have terrible performance because it will iterate the entire thing using the iteration protocol.

Hopefully this can be optimized internally without explicit changes in the spec. And in the worse case, wouldn't this just have the same performance as .push(...iter)?

Iterator.concat is a constant-time operation.

That returns a new object, which I think this is trying to avoid else we would just be writing arr.concat().

Is there a case where people are working with such large data and still need array-like behaviour such as constant-time indexing or length checking?

I have a case within the last week that requires flattening into an array that can be iterated multiple times, and can be reversed. It's not millions of items, but still requires an array. I'm ok with .push(...arr), but I would have used pushAll() were it avilable.

[michaelficarra]

And in the worse case, wouldn't this just have the same performance as .push(...iter)?

Sure, and for very large values, I'm skeptical whether that would have met their performance goals if it had worked.

That returns a new object, which I think this is trying to avoid else we would just be writing arr.concat().

arr.concat has the same issue. It doesn't use the iteration protocol, but it eagerly copies the entire argument. Iterators would defer that.

I have a case within the last week that requires flattening into an array that can be iterated multiple times, and can be reversed. It's not millions of items, but still requires an array.

I'm strictly interested in cases where people are hitting these artificial limitations in practice. It sounds like your use-case is not quite that size, especially given you're able to iterate it multiple times and reverse it.

[jridgewell]

arr.concat has the same issue. It doesn't use the iteration protocol, but it eagerly copies the entire argument. Iterators would defer that.

I'm saying neither concat is useful, it returns a new object instead of mutating.

[DanielRosenwasser]

You could make the argument that in some cases, an iterator would make more sense. It feels pretty clear that that isn't always the case (e.g. the array just has to exist because you received it externally, or because you want pre-process the data before the append, or because generators may actually be slower than the appends).

I think iterators having desirable characteristics in lots of valid scenarios doesn't negate the value of better APIs for Arrays.