Should be syntax, not method

[tabatkins]

While methods are definitely easier to deal with and are generally less controversial, something in the [] syntax is much better because it allows using the ability in the LHS of a = operator. If we did a .last() method or something, you'd still have to resort to arr[arr.length-1] = foo; to set the last value.

(If we pull this off right, we could also slide in Python-style slice syntax, and then people can finally forget about .slice() (for getting) and .splice() (for setting/deleting), which would be a huge usability win.)

[keithamus]

you'd still have to resort to arr[arr.length-1] = foo;

I've updated the proposal to be a getter/setter. So this is no longer an issue... however...

we could also slide in Python-style slice syntax

I am still very keen on seeing this idea. I think we could potentially see both in the language though - as a slice syntax solves a host of other problems.

I'll close this purely on the merit that this proposal solves once specific problem of avoiding math on .length for simple use-cases.

[tabatkins]

Please re-open. While I'm fine with us only solving the "last value" (or nth-last value, per #5) here, it's valuable to capture the request for this to cover slicing use-cases as well, for evaluating the proposal as it advances.

[gsathya]

FYI, here's a proposal for slice notation that I plan on bringing up at the next meeting: https://github.com/gsathya/proposal-slice-notation

[Enteleform]

+1 for a syntactic implementation.

Python handles this very cleanly:
arr[-1]
arr[-1] = foo

This also allows setting & retrieving the nth index from the end of an array, rather than only the last element:

let arr = [0, 1, 2, 3, 4]

console.log( arr[-1] ) // 4
console.log( arr[-2] ) // 3

arr[-2] = 300

console.log(arr) // [0, 1, 2, 300, 4]

[photonite]

@Enteleform
What would be the case here?

let arr = [];

arr[-3] = 1;

console.log(arr);
console.log(arr.length);

Would it have the same behavior as positive indices, hence arr would be [1, empty × 2] and its length would be 3?

let arr = [];

arr[3] = 1;

console.log(arr); // output: [empty × 3, 1]
console.log(arr.length); // output: 4

[Enteleform]

@photonite

Hadn't used manual index assignment in that way before, didn't know about the auto-population of empty values in JS. Python is a bit more strict about indexing, and throws IndexError: list index out of range in such cases.

The [1, empty × 2] example you posted makes sense for maintaining consistency with the existing index assignment behavior.

[photonite]

There would be one concern however as currently you can set array properties with keys being negative numbers (or floats).

example:

let arr = [];
arr[1] = "first";
arr[-3] = "prop";

console.log(arr); // [ empty, "first", -3: 1 ]
console.log(arr.length); // 2

notice that the length is 2 and not 3. as the prop -3: 1 is not being counted.

if the negative indices were implemented to allow accessing array items from the end, it would not be possible to set properties with negative numbers as key.

I do not find that big of a deal because I believe it is not that common to set properties on arrays, and even less common to give them negative numbers as keys, but it is a compatibility concern with older code.

[ljharb]

(It's a sufficient compatibility concern that it's an immediate nonstarter, ftr)

[atg]

What is the evidence that it is a compatibility concern?

[ljharb]

When considering breaking existing code, the burden of providing evidence is a bit more on those who think it’s not a concern. What is the evidence that nobody is relying on this behavior?

[Zarel]

@atg There are some examples in #1, for instance:

const array = [1, 2, 3];
const itemIndex = array.indexOf(5); // -1
if (array[itemIndex]) {
    // ...
}

would be broken.

[Enteleform]

@ljharb

(It's a sufficient compatibility concern that it's an immediate nonstarter, ftr)
...
When considering breaking existing code, the burden of providing evidence is a bit more on those who think it’s not a concern. What is the evidence that nobody is relying on this behavior?

Agreed, but it's unfortunate that there's not a proper major/minor versioning system in place to allow these kinds of changes in major version releases. The dictionary-ish behavior of arrays that @photonite mentioned is not idiomatic (for arrays, from a language-agnostic standpoint), and is a side-effect of JS objects essentially being dictionaries.

IMO, JavaScript would benefit greatly from not being bound to constructs that were implemented before it evolved to it's current scope & ubiquity. It seems that the ECMAScript evolution is on a perpetual minor versioning system, requiring complete backwards compatibility, which is holding the language back in terms of eloquence & conciseness. If we have to worry about backwards compatibility forever, then we're always going to have deprecated artifacts & workarounds like var, array.lastItem, etc; and they'll only increase in number.

[ljharb]

@Enteleform We effectively do have to worry about it forever; that's the nature of web compatibility.