Consider specifying `Array.prototype.keys()` and friends to return a numeric range iterator

[dead-claudia]

The title says it all. It in effect is the same thing, and it'd make it much easier to implement. It'd also make optimizations more straightforward for them.

I've seen a few polyfills rely on Object.getPrototypeOf([].keys()) to get %ArrayIteratorPrototype%, so it may be worth checking that for web compatibility and seeing if they can migrate elsewhere well enough to mitigate that. However, my gut feeling is that the idiom Object.getPrototypeOf(Object.getPrototypeOf([].keys())) to get %IteratorPrototype% would amount to almost 100% of uses for that, so that would also need differentiated somehow in web compat checks (like maybe with an execution context-global boolean).

[jridgewell]

This would cause a change in behavior, since ArrayIterator tracks the array after mutations:

const a = [1, 2, 3];
const k = a.keys();

// Mutate the array
a.pop();

// Keys iterator will not include 2.
[...k] // => [0, 1]

[dead-claudia]

@jridgewell How many people rely on that? I could see .values() having more than a few, but .keys() is pretty niche to begin with.

[ljharb]

It’s likely that es6-shim and core-js both would break if this change was made. It’s worth verifying, but I’m not optimistic.

[dead-claudia]

And knowing how unlikely people are to update those modules, I'm starting to agree with you that it's very unlikely to be doable.