Negative indices

[azz]

It seems strange to me to just spec out array[:-1] or array[-1] and not allow other negative indices. Why not propose array[:-N]?

[keithamus]

This is just to propose the solution of array-last. The idea is to open the discussion about values such as array[:-N] but to try to avoid any scope creep about this specific rationale

[keithamus]

So to clarify - if the committee decides that array[:-1] could be a viable option, then array[:-N] would absolutely be up for discussion/proposal.

[tabatkins]

I am very strongly of the opinion that specializing this to just the literal last element would be a terrible mistake and not worth the effort of speccing and implementing it. Anyone with experience in langs that allow negative indexes, like Python, can tell you that while -1 is the most commonly used one, larger values aren't uncommon either.

In other words, imo the discussion should start from the assumption that we'll be allowing negative indexes, and just shut off any options that wouldn't allow that. (This removes .last, Symbol.last, etc.)

[keithamus]

Closing this. The Readme has been updated to reflect the current state of this proposal which features Array.prototype.end getter/setter.

[tabatkins]

Please reopen - the current state of the README explicitly disagrees with this issue, so it's valuable to capture this dissent as the proposal is reviewed.

[hybrist]

There's also the possibility of having [].get(-1) which would be somewhat consistent with both [].slice(-1) (index semantics) and new Map().get(idx) (naming of the method).

[uniqname]

This feels premature so long as a more generalized proposal, such as arr[-N] is an option. Should the generalized options fail, something like this makes a lot more sense. Pursuing them both simultaneously I fear undercuts the arguments for either. Perhaps the committee has a mechanism for reconciling these kinds of overlapping proposals though.

[trotyl]

@uniqname arr[-N] is NOT an option, see #1.

[Mottie]

If you really want negative indices now, check out https://github.com/sindresorhus/negative-array; I like the idea and would consider using it in future projects.

[rauschma]

I’d love to have .get(i) and .set(i, x) with support for negative indices: as @jkrems mentioned, they’d be consistent with current collection interfaces (Map etc.).

I remember there were arguments against those methods, but forgot what they were.

[ggranum]

With regards to this proposal: If we are convinced that negative indexing is far, far on the horizon, then I support anything along the lines of [1,2,3].last and [1,2,3].last = 100. The shorter the better, but anything reasonable provided it does nothing that could make implementing direct ( ary[-2] ) negative indexing less likely.

While I really vastly prefer and would love to discuss negative indexing and argue in favor of ary[-N], despite the need for a feature flag, I believe that the scope of this discussion needs to be limited to this proposal with respect to negative indexing.

As such, I do agree with @uniqname - shooting for this feature could reduce demand and drive for negative indexing. However, the ability to quickly and explicitly access 'last' is valuable, even with negative indexing available. I think ary.last = 100 is more clear and descriptive than ary[-1] = 100, and could have a place even in a world where both are options.

If negative indexing were here today, I'd lean against adding this feature due to the very minor value it adds in a world with negative indexing already available. However, negative indexing is unlikely to be added all that soon, simply because breaking things or adding a feature flag is contentious, and modifying the most obvious solution simply to avoid breaking things or adding a feature flag is also contentious.

[Zarel]

I'd like to chime in with support for .get(-1) and .set(-1, value)

• they allow access to arbitrary distances from the end, not just the last value
• they're consistent with Map
• they don't use getters/setters, which are a bit too magical for my tastes (setters especially - setting a property shouldn't have any side effect other than setting that property)
• they can be polyfilled in ES3 engines