Skip to content

Iterator helpers vs this proposal #1

Closed
@zloirock

Description

@zloirock
Contributor

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

Activity

zloirock

zloirock commented on Aug 19, 2021

@zloirock
ContributorAuthor
js-choi

js-choi commented on Aug 19, 2021

@js-choi
Collaborator

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

zloirock commented on Aug 19, 2021

@zloirock
ContributorAuthor

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

js-choi commented on Aug 19, 2021

@js-choi
Collaborator

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

zloirock commented on Aug 19, 2021

@zloirock
ContributorAuthor

Maybe you're right.

Jamesernator

Jamesernator commented on Aug 22, 2021

@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.

locked as resolved and limited conversation to collaborators on Aug 23, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @js-choi@zloirock@Jamesernator

        Issue actions

          Iterator helpers vs this proposal · Issue #1 · tc39/proposal-array-from-async