Accept non-iterator array-like inputs, like Array.from?

[js-choi]

Array.from accepts non-iterable array-like inputs (objects with a length property and indexed elements).

Should the inputs of Array.fromAsync be a superset of Array.from?

[ljharb]

It absolutely should accept them.

[zloirock]

Iterators helpers and collections .from does not handle non-iterables. However, it can be added for consistency with Array.from. But how? Array iterator -> async-from-sync iterator - and iteration over it, just iteration over array-like object or something else?

[js-choi]

I don’t think iterator helpers need to accept non-iterator array-like inputs. iter.toArray was never going to completely match Array.from, right?

[zloirock]

(Async)Iterator.from, (Weak)(Map|Set).from.

[js-choi]

Oh, ah, right, I had forgotten about those. Well, yes, those might want to match Array.from in taking non-iterable array-like inputs. We should open an issue there.

[zloirock]

I'm not sure that handling non-iterables should be added to all .from methods. Array-like is an obsolete protocol for collections that was replaced by the iterable protocol in ES6. Array-like objects are... array-like, so they could be transformed into arrays, they are sync, so I don't think that makes sense to handle them async - Array.from is enough. It's a legacy protocol, so I don't think that makes sense to add it to new features. Because of this, new features that accept collections support only iterables, but not array-like objects - for example, collections constructors like Set.

[ljharb]

It's very much not obsolete, and it's very nice that things aren't forced to implement the iterator protocol to be transformable into an Array.

This proposal must match Array.from's semantics, which includes every feature it has - just like new array methods still include a receiver argument, despite that being obsolete.

[zloirock]

It's very much not obsolete, and it's very nice that things aren't forced to implement the iterator protocol to be transformable into an Array.

How many new features are array-like and not iterable? The iterable protocol is the standard for handling collections. It's a bad practice not to use iterators protocol where it can be used.

It's not hard to implement iterators protocol on a userland array-like - just add [Symbol.iterator]: [].values.

just like new array methods still include a receiver argument, despite that being obsolete

It was decided not to add this argument to new features. It's added only to new completely similar to old features. For example, this argument was not added to (Async)Iterator.prototype methods similar to Array.prototype methods.

This proposal must match Array.from's semantics

It's like to say that new array prototype methods should not handle holes as undefined like old methods.

[ljharb]

There's a difference - holes are bad and should never have been a thing, arraylikes are fine and have use cases beyond iteration.

[zloirock]

Array-like objects are fine, but for interaction with modern infrastructure, they should be also iterable. For handling legacy non-iterable array-like objects already available sync Array.from, any other methods haven't fallbacks for this legacy.

[ljharb]

I agree with you there. The sole purpose of these .from methods is to not have to think about the legacy stuff - in other words, you can always feed them legacy things, and you get proper, non-legacy things out.

[zloirock]

Let it be. But let's return to this:

But how? Array iterator -> async-from-sync iterator - and iteration over it, just iteration over array-like object or something else?

[bakkot]

I guess I'm OK with it, but I'm not totally convinced. fromAsync is useful specifically for async iterables. I have a hard time imagining why reasonable code would ever want to pass it an array-like (which is by definition synchronous).

[js-choi]

But how? Array iterator -> async-from-sync iterator - and iteration over it, just iteration over array-like object or something else?

Yeah, I think it would just return a promise that resolves to the array that would have been created by Array.from.

---

I guess I'm OK with it, but I'm not totally convinced. fromAsync is useful specifically for async iterables. I have a hard time imagining why reasonable code would ever want to pass it an array-like (which is by definition synchronous).

I imagine people will be occasionally passing sync iterables to fromAsync when they’re not sure whether it’s an async or sync iterable, just how they might be doing so with for await. That’s all I have for use cases. Separately, consistency is important.

---

Also, I created tc39/proposal-iterator-helpers#155.