Iterator helpers vs this proposal

[zloirock]

Stage 2 iterator helpers proposal already contains %AsyncIteratorPrototype%.toArray method that does absolutely the same. What are the advantages has Array.asyncFrom?

[zloirock]

@js-choi

[js-choi]

Sorry, didn’t notice this issue. I plan to discuss this in the slides but I should have addressed this in the explainer, too.

Array.from already exists, and Array.asyncFrom would parallel it. If we had to choose between asyncIterator.toArray and Array.asyncFrom, I would argue that we should choose the latter for its parallelism with what already exists.

In addition, the iterator-helpers proposal’s syncIterator.toArray already duplicates Array.from. Duplication with an Array method seems to be considered not important anyway. If duplication between syncIterator.toArray and Array.from is already okay, then duplication between asyncIterator.toArray and Array.asyncFrom should also be okay.

I will add a section to the explainer discussing this proposal’s relationship with the iterator-helpers proposal.

[zloirock]

The creation of helpers for special cases, moreover - duplicated, looks wrong.

Much better to create a universal protocol for the conversion of anything to anything else.

See tc39/proposal-iterator-helpers#36. It's explained for iterators / iterables, but also works for async iterators / iterables too - see the final example.

[js-choi]

I definitely agree that a general, unified, extensible conversion protocol would be nice and should be proposed in the future – perhaps somehow integrating with transducers.

However, Array is JavaScript’s fundamental collection type, and it is privileged in both syntax and API. Having first-class methods for converting to it would be convenient for any developer working in JavaScript.

Incrementally extending that use case is the narrow scope of this narrow proposal. Creating an extensible conversion system would require much more deep thought, and deep thought is not necessary to handle this proposal’s specific use case today.

(As an aside, it may make sense to add both Tuple.from and Tuple.asyncFromin the future – likewise for Object.asyncFromEntries and Record.asyncFromEntries. These data types, too, are privileged by the language in syntax and API. There are many such “duplicated” parallel methods across many built-in classes, and in fact that parallelism improves usability.)

A general, unified, extensible conversion system is a great idea. But it probably would have enough cross-cutting concerns to warrant its own individual, separate TC39 proposal. I encourage you to write a separate proposal and seek a TC39 delegate to champion it. It is out of scope of this narrow proposal.

[zloirock]

Maybe you're right.

[Jamesernator]

There is the old stage 1 proposal for of/from on all iterable collections. It would make sense if all such collections were specified to additionally have asyncFrom in addition to of/from as well.

Although given the other proposal has been in Stage 1 for years with no progress, I think this proposal focusing on just Array is fine. If the other proposal did make progress though, it would make sense to include asyncFrom in it.