toArray and Array.fromAsync

[js-choi]

Spinning this off tc39/proposal-array-from-async#3.

This proposal’s toArray method overlaps with another proposal that recently reached Stage 1, Array.fromAsync. toArray already overlaps with Array.from too.

My preference is to keep both toArray and Array.fromAsync (Array.from being a fait accompli). I think they do somewhat different things. And I remember @michaelficarra saying that he had a vision of eventually extending toArray to handle coercion to other data types.

#155 is slightly related to this.

CC: @bathos, @codehag

[ljharb]

We should have both.

[michaelficarra]

@js-choi We had discussed toArray potentially taking other constructors for data structures to build, but my thinking now is that, at best, it would just pass the iterator back to a "buildable" interface on the passed constructor. See my comments at https://matrix.to/#/!WgJwmjBNZEXhJnXHXw:matrix.org/$SSPy_051snQ02aNV60qTkkUPzB4JXphTfwFYWWdWrAI

Michael Ficarra | yulia: I remembered why it's better for a buildable structure to consume an iterable than for an iterable to consume a buildable protocol | 19:13:33
Michael Ficarra | sometimes building something one element at a time is the same as building it >1 element at a time, but sometimes it could be slow to build that way or produce a structure with equivalent semantics but different performance properties | 19:15:21
Michael Ficarra | so it's best for the buildable thing to control how it consumes the iterable | 19:15:35
Michael Ficarra | something like discussed here: #36 | 19:22:46

[bakkot]

(simpler logs link: https://matrixlogs.bakkot.com/TC39_Delegates/2021-08-31#L558-L561)

[michaelficarra]

I think toArray and Array.fromAsync can co-exist.