Array.prototype.at compatibility?

[Nemo64]

I noticed that there is an .at method in the Array prototype in stage 3.
It seemed kind of useless to me for cases like [1, 2, 3].at(2).

But if iterators also implement it, then it'll suddenly make sense for compatibility between the Arrays and Iterators.

function getFirstStringItem(list: Iterable<any>): any {
    return list
        .filter(item => typeof item === 'string)
        .at(0); // would work with arrays and iterables
}

Implementing it with negative integers would require going though the entire iterator though.

Also, the iterator would be consumed by this wich might result in unexpected behavior:

function items(list: Iterable<any>) {
    return [
        list.at(0),
        list.at(1), // this would (probably) behave differently between arrays and iterators
    ]
}

[ljharb]

Iterators don’t inherently have indexes, and the length can’t be known ahead of time - “at” would have to be like “take” and then “drop”, throwing away all the items up to that “index”.

[Nemo64]

The negative index discussion is also in #131 so i'd say this depends on the outcome there.
And yes, .at(2) would be basically equivalent to .drop(2).next().value or .slice(2).next().value

[bakkot]

Apart from the negative index issue, I dislike using at for this because it has dramatically difference performance characteristics than it does for arrays and strings, so it will be easy to write quadratic code where identical code would be linear in another context.

[bathos]

Assuming there's no proposal for "number of times next has been called" to become a built-in component of iterator state, it seems like iter.at(1) === iter.at(1) would have to be false (I mean, assuming the iterator doesn't just happen to yield the same value). The name at implies random access to me, not a state transition.

Rather than .at(2), .drop(2).next().value seems more like e.g. skipToValue(2). This is not an actual name suggestion, just saying that whatever name it did have should probably communicate something along those lines (that the index is relative to the current iterator state, etc).

[js-choi]

To add onto @bathos’s comment, Clojure uses nth versus get to distinguish linearly accessing the nth value from a sequence (consuming previous items in the process) from randomly accessing a value by a key from a vector or map object. As with Clojure sequences, nth might be a good name for linear access in JavaScript iterators too.

[michaelficarra]

This doesn't provide much value over the proposed alternatives. We should not expand the proposal to include this method. If you would like, you can make a follow-on proposal, but I don't think this method will justify itself.