You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Removes use of %Array.prototype.values%.
Closes#29.
Maybe in the future we can come back to this and simplify both Array.from and Array.fromAsync with %Array.prototype.values%. Because we haven’t confirmed that this is truly unobservable, today is not that day.
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 #14 (comment) that we could eventually apply this simplification to Array.from as well.
However, @bakkot pointed out a potential problem on Matrix:
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.
The text was updated successfully, but these errors were encountered: