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

Using %Array.prototype.values% #29

Closed js-choi closed 2 years ago

js-choi commented 2 years ago

Right now, the proposed algorithm uses %Array.prototype.values%, CreateArrayIterator, and %ArrayIteratorPrototype%. This is a shortcut for the machinery that handles non-iterable array-like objects, like Array.prototype.values does. @ljharb pointed out in https://github.com/tc39/proposal-array-from-async/issues/14#issuecomment-1020326595 that we could eventually apply this simplification to Array.from as well.

However, @bakkot pointed out a potential problem on Matrix:

Array.prototype.values produces an iterator which uses the current value of %ArrayIteratorPrototype%.next, which is not what Array.from does[,] so it's not a totally straightforward refactoring

This may also be a problem for Array.fromAsync. We need to closely examine whether we can refactor Array.from and Array.fromAsync to use %Array.prototype.values% without any observable difference. The intent has always been to make sure that Array.fromAsync follows Array.from in its treatment of non-iterable array-like objects.

If we are not able to do this soon (before @nicolo-ribaudo and @ljharb perform their Stage-3 reviews again, with the goal being the 2022-09 plenary), then we may have to switch this proposal’s specification not to use %Array.prototype.values% and to defer refactoring to use %Array.prototype.values% later, after this proposal is accepted for Stage 4. See also #23.

ljharb commented 2 years ago

Given that problem, which had not occurred to me, it'd indeed probably be simpler for now to remove the values simplification in this proposal.