Drop .toArray from this proposal

[btoo]

.toArray seems needlessly specific since arrays are not the only things that iterators will need to be converted to

It's also redundant because Array.from already exists. Would it not be better to leave it up to each class to implement its own iterator -> class instance constructor (Object.fromEntries, new Set/Set.from, etc.)?

[ljharb]

Array.from isn’t chainable, and arrays are, by a large margin, the primary thing iterators are converted into.

[bakkot]

See #36 (comment).

[btoo]

Array.from isn’t chainable

imo (and it is just an opinion), chainability for non-array-like methods should be de-prioritized while the resolution of the pipeline operator proposal is underway

arrays are, by a large margin, the primary thing iterators are converted into.

See #36 (comment).

i think this offers a great reason not to add a generic .to method, but i would extend this way of thinking to any .to*. if array's are privileged in this context, why can't objects be too? I'm worried this is a slippery slope that results in stuffing too many features into the proposal

[bakkot]

if array's are privileged in this context, why can't objects be too?

Because arrays, like iterators and unlike objects, represent a sequence. Arrays are a natural thing to transform iterators into in a way that objects are not.

I'm worried this is a slippery slope

It's exactly one additional, very useful method. The champions have repeatedly refused requests to add other variations. I don't think this slope is very slippery.

[btoo]

Because arrays, like iterators and unlike objects, represent a sequence

I think the presupposition that iterators represent a sequence is biased. Yes, they ultimately take form as a sequence, but only because of their lazy nature. It's easily conceivable that developers are using iterators just as collections (orderless)

[ljharb]

That doesn’t make any sense to me. A collection doesn’t have an order, iterators do. Certainly iterating an unordered collection requires choosing an order, one that may not matter in that use case, but that doesn’t affect the semantics of iterators - which is, explicitly and unavoidably, an ordered sequence of values.

[btoo]

i get that iterators are structured sequentially, but my point is that the intent with which people use them is not necessarily as a sequence

to give an analogous example, arrays are often used to create objects, but they don't have their own .toObject method (that's Object.fromEntries's responsibility) because they are not necessarily intended to be used as enumerated object entries

[Nemo64]

I just want to throw in that there is the pipeline proposal: https://github.com/tc39/proposal-pipeline-operator/wiki
It would allow to do something similar to this.

naturals()
    .filter(n => n > 20)
    .take(20)
    |> Array.from(?)

It looks kind of wrong but it would make it easy to just chain the result in Object.fromEntries Array.from etc.

[btoo]

yep i agree. it's why i mentioned

chainability for non-array-like methods should be de-prioritized while the resolution of the pipeline operator proposal is underway

[michaelficarra]

Arrays are extremely privileged and ubiquitous. For that reason, the toArray helper pays for itself.