Closed
Description
Stage 2 iterator helpers proposal already contains %AsyncIteratorPrototype%.toArray
method that does absolutely the same. What are the advantages has Array.asyncFrom
?
Stage 2 iterator helpers proposal already contains %AsyncIteratorPrototype%.toArray
method that does absolutely the same. What are the advantages has Array.asyncFrom
?
Activity
zloirock commentedon Aug 19, 2021
@js-choi
js-choi commentedon Aug 19, 2021
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, andArray.asyncFrom
would parallel it. If we had to choose betweenasyncIterator.toArray
andArray.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 duplicatesArray.from
. Duplication with anArray
method seems to be considered not important anyway. If duplication betweensyncIterator.toArray
andArray.from
is already okay, then duplication betweenasyncIterator.toArray
andArray.asyncFrom
should also be okay.I will add a section to the explainer discussing this proposal’s relationship with the iterator-helpers proposal.
zloirock commentedon Aug 19, 2021
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 commentedon Aug 19, 2021
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
andTuple.asyncFrom
in the future – likewise forObject.asyncFromEntries
andRecord.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 commentedon Aug 19, 2021
Maybe you're right.
Jamesernator commentedon Aug 22, 2021
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 haveasyncFrom
in addition toof
/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 includeasyncFrom
in it.