search

tc39 / proposal-array-from-async

Draft specification for a proposed Array.fromAsync method in JavaScript.
http://tc39.es/proposal-array-from-async/
BSD 3-Clause "New" or "Revised" License
177 stars 13 forks source link

Iterator helpers vs this proposal #1

Closed zloirock closed 3 years ago

zloirock commented 3 years ago

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

zloirock commented 3 years ago

@js-choi

js-choi commented 3 years ago

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 commented 3 years ago

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 https://github.com/tc39/proposal-iterator-helpers/issues/36. It's explained for iterators / iterables, but also works for async iterators / iterables too - see the final example.

js-choi commented 3 years ago

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 commented 3 years ago

Maybe you're right.

Jamesernator commented 3 years ago

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.