Stage 3 Proposal: Array.prototype.at

https://tc39.es/proposal-relative-indexing-method/

by bpierre • 5 years ago

80 144 5 years ago

tc39.es

ezekg• 5 years ago

Am I reading this correctly — it's an alias for arr[i] and str[i]? I know languages like Ruby have arr.at(i), but why?

twoodfin• 5 years ago

A quick read suggests that it adds negative indexing from the end of the array.

Pxtl2• 5 years ago

Imho that violates the principle of least astonishment - that "at" would have such different behavior from "[]" for negative numbers.

pininja• 5 years ago

Accessing negative indexes currently returns undefined. This adds support for indexing from the end of an array with negative numbers.

franciscop• 5 years ago

This works, but not the way you'd think:

    const arr = [];
    arr[-1] = 'Hello world';
    console.log(arr[-1]);
    // Hello world

Instead of using the negative index, it stringifies the "-1" and uses it as the key of an object both when writing and reading. Thus, arr.length still remains 0

maweki• 5 years ago

It's a function object then.

nvartolomei• 5 years ago

Proposal hosted on GitHub explains the reasoning behind it https://github.com/tc39/proposal-relative-indexing-method

antris8• 5 years ago

In addition to negative index support, a function is more easily composable e.g. converting a list of indices to a list of objects: `indices.map(myObjectArr.at)`

I've lost count on how many times I've wrote this function manually.

bidirectional• 5 years ago

`indices.map(myObjectArr.at)`

That works in this case, but eta-reduction is not generally safe in Javascript due to the variadic nature of many functions, so I wouldn't recommend it in production code. For example `indices.forEach(console.log)` does not work as one would expect.

joppy2• 5 years ago

The alternative being the pretty-much-just-as-short indices.map(i => myObjectArr[i])?

inbx0• 5 years ago

That will break with

Uncaught TypeError: Cannot convert undefined or null to object

because `myObjectArr.at` doesn't bind `this` to `myObjectArr`. When the internals of `map` call the `at` function, `this` is just `undefined` instead of the original array and it'll throw.

Luckily Array.prototype.map takes a second argument just for this purpose

    indices.map(myObjectArr.at, myObjectArr)

Phenix88be• 5 years ago

So instead of fixing the language and allow to use array[-1], they add an other way to access array element. This is why I don't like JavaScript, instead of fixing feature, they add new feature to fix previous feature.

Spivak• 5 years ago

The problem with JS language development is the mountain of code that it would break if you do anything except append features.

    array[-1] = “foo”

This already works in JS but doesn’t do what you expect and just assigns the property.

cogman103• 5 years ago

Javascript array indexing is a MESS. This

    array["foo"] = "bar"

is valid javascript.

kevincox• 5 years ago

To be clear this is equivalent to array["-1"] (unless you do horrible things overriding the built in types). Since arrays are "just" objects in JavaScript it is completely valid to add a property called "-1" to it.

wereHamster• 5 years ago

There is existing code out there which relies on negative indexes to return undefined. Or relies on being able to assign items to negative indexes and then retrieve them, this is perfectly valid code: `a=[];a[-1]=42;console.log('the answer is',a[-1])`. The web tries really hard to be backwards compatible and not break existing code.

eknkc• 5 years ago

Maybe we should re utilize the "use strict"; type of metadata. Something like "use es2021" to enable negative indexes etc.

kreetx• 5 years ago

How about deprecating that for a few years then? Doesn't seem good to keep the behavior, given that it will also be confusing in the future.

But perhaps we just don't know enough, and they will add the `at`, and at some point actually do bind `arr[index]` to use the implementation of that function?

playpause• 5 years ago

New features are added to JavaScript very carefully to avoid breaking existing code on the web. The downside is you often end up with multiple ways to do the same thing, but there are ways to mitigate this, like using a linter to enforce using a modern subset of the language.

jasonzemos• 5 years ago

That's starting to sound an awful lot more like C++.

kevingadd• 5 years ago

Adding this wouldn't be backwards compatible, so it can't be done. Simple as that. It's not broken, either - it just doesn't do the thing you want.

JoBrad2• 5 years ago

It is consistent with slice, though. Neither changes the implementation of the array, they just provide ergonomic benefit to the developer.

xdennis• 5 years ago

fixing

I dislike the abuse of this word. Lacking some shorthand notation doesn't make the language "broken".

It reminds me of handling support tickets where clients say "X needs to be urgently fixed" even though X has never been possible. (Should it? Often yes, but it doesn't mean it's broken.)

trinovantes• 5 years ago

This is going to confuse C++ developers where vector::at() explicitly throws exceptions on out of bounds access

But I guess the intersect between C++/JS developers is too small to care

yoz-y• 5 years ago

As one of those c++/js developers I'd just say that I do not map concepts from one language to another because it rarely works anyways.

IshKebab• 5 years ago

I agree. I would expect it to throw an exception.

However I think there is a better way to support that - make `throw` an expression rather than a statement. Then you can do

    a[10] ?? throw new Error()

which currently doesn't work.

sfinx• 5 years ago

If I understand this correctly it is to add negative index support to arrays. How will findIndex work when this is introduced? It currently uses -1 as a return value when no element satisfies the testing function.

jakelazaroff3• 5 years ago

You can’t have a negative array index. Passing a negative number will just make this function count backwards instead of forwards.

[1, 2, 3, 4].at(0) === 1

[1, 2, 3, 4].at(1) === 2

[1, 2, 3, 4].at(-1) === 4

findIndex’s behavior is unchanged.

almost• 5 years ago

It’s not adding negative indexes, a negative number will index from the end.

So [0, 1, 2, 3].at(-2) === 2

onion2k2• 5 years ago

That would mean getting the last element of the array would be [0,1,2,3].at(-1).

I don't like that very much.

Mind you, I don't like the idea of using [0,1,2,3].at(-0) either...

pedrow2• 5 years ago

Python also uses negative indexes in this way, see https://docs.python.org/3/library/stdtypes.html#common-seque...

onion2k2• 5 years ago

Array.prototype.at would only ever return the value of something in the array at the index requested (or undefined). It'd accept a negative offset, but that's not the index of the thing you're looking for; it's an offset from one end of the array.

pedrow2• 5 years ago

In the proposal text, what's the meaning of the '?' and '!' - for example in "Let O be ? ToObject(this value)"

IainIreland2• 5 years ago

Roughly speaking, '?' means that the operation might throw an exception, which should be propagated if thrown, and '!' means that the operation should never fail. (In Rust terms, '? ToObject(this value)" -> "ToObject(thisValue)?", and "! ToObject(this value)" -> "ToObject(thisValue).unwrap()".)

See: https://tc39.es/ecma262/multipage/notational-conventions.htm...

dlojudice• 5 years ago

JS urgently needs support for decimals [1] and thus be able to enter sectors such as scientific and financial.

V8 + dynamic language + better math support = perfect environment for many applications out there

[1] https://github.com/tc39/proposal-decimal

cogman103• 5 years ago

Couldn't that be done with WASM today? It looks like a few people have managed to build GMP targeting WASM.

You might miss out on some SIMD operations, but you'd be able to do 90% of what you'd want with scientific calcs. (admittedly, it'd be nice if this were part of the language).

diamond_hands• 5 years ago

There's still a ton of overhead for WASM and it's not first class. Using WASM is a lot like using C code in python. It's still nice to have features as first class citizens :)

runarberg5• 5 years ago

Honest (possibly stupid) question: Do people working on statistical and probability application never need a numeric type optimized for probability values (i.e. values between 0 and 1 that can get really close to either; for example the really almost certain value of p = 1 - 10^-13)? In the same way that financial application needs a decimal type?

I’ve only worked on probability applications at a surface level for a tiny bit and never really needed it, but I kept wondering whether there were such a numeric types, and if not, what people did if they needed it.

joppy2• 5 years ago

Log probabilities are used a bit for this, and most numeric packages (numpy for instance) have special functions for computing log(1+x) which are more accurate when x is tiny.

6gvONxR4sf7o2• 5 years ago

This would be really nice, but the only solution I know here involves working with numbers that represent a function of p rather than p itself. And what you do depends on what you're computing. In general, you'll find lots of useful math functions that have specialized routines around zero and one, like numpy's log1p function, logaddexp, expm1, and company.

Log odds ratios are also good representations that have this kind of accuracy between zero and one. They're good when you need them. (e.g. 100:1 odds are log(100/1) and 1:100 odds are log(1/100))

Aardwolf• 5 years ago

For financial makes sense, but science should be independent of numerical base?

ihuman2• 5 years ago

I think the issue isn't the base, but that Javascript stores all numbers as 64-bit floats.

z3t42• 5 years ago

We also have a unix timestamp issue coming up.

xhrpost• 5 years ago

Very good point. I'm just now fully understanding why at my last fin-tech job we stored all monetary amounts in pennies. I thought at first it was just ideal to keep everything as integers in the database but I see now that due to our Node backend, something as simple as 0.20 + 0.10 could pose a problem.

spankalee• 5 years ago

That's not due to Node, that's due to IEEE 754 standard floating point operations.

erikpukinskis• 5 years ago

What would the benefits of a language native implementation be, over something like decimal.js?

Is it just a matter of there being a "blessed" implementation for folks to standardize around?

ranguna• 5 years ago

Universal support for third party integrations such as connecting with a database that allows for arbitrary precision decimals, communicating with other services without forcing a use of a random lib (because there are many that do this kind of thing).

Support for this I believe is "low level enough" to ve implemented natively, it's not something like protobuf.

beaconstudios10• 5 years ago

    const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i];

Why does the core language need to be extended to incorporate this?

zodiakzz4• 5 years ago

Just Google "left-pad" to know why. I think .at() also doesn't have to look up the entire prototype chain so it has performance benefits as well.

beaconstudios10• 5 years ago

    const leftpad = (str, len, char = ' ') => str.length >= len ? str : (char.repeat(len - str.length) + str);

Anybody who installs a dependency instead of writing a one line function is just leaving themselves exposed for no real benefit.

Providing the at function outside of the prototype chain like I did above will not incur the cost you mentioned, even in the unlikely case that such calls are the bottleneck of your application.

Plus, if array lookup calls are your bottleneck then you probably need a different data structure.

Cthulhu_• 5 years ago

Because at some point someone will - and probably has - make a library out of this, adding yet one more to the tens of thousands of files that my cruddy server can't handle already because of the sheer quantity.

Plus you're probably missing a few dozen edge cases and optimizations that the native version would incorporate.

We wouldn't have been in node_modules dependency hell if they incorporated a few more things into the standard library or language.

beaconstudios10• 5 years ago

in my experience, the vast majority of node modules I have installed don't provide these tiny little functions, but are:

- frameworks like react or express and extensions for the same

- meaningful libraries like axios, ramda, date-fns or qs

- transpiler/bundler enhancements like webpack loaders or babel presets

I would prefer that the JS committee focused on bringing meaningful new capabilities to node and the browser that are currently lacking, like they did with the various HTML5 libraries, fetch(), ES classes and so on, rather than providing tiny functions that aren't even providing new functionality (array indexing is easy and idiomatic in JS). If there was no opportunity cost then sure, add tiny pointless builtin functions all day long.

londons_explore3• 5 years ago

optimizations that the native version would incorporate

We shouldn't write stuff in native code for performance... We should write the compiler to detect these and output optimized code.

jahewson• 5 years ago

Array parameter should be last, surely? Or why not extend the prototype? If only we had some way to standardise such decisions...

johnfn• 5 years ago

Subtle readability improvements on patterns that see extensive use actually make a difference.

I had the exact same thoughts when `.includes()` was proposed to be added to the spec - it's just `.indexOf() !== -1`! - but time has proven me wrong, and I suspect it will prove us wrong about `at` as well.

I've written an `.indexOf() !== -1` check hundreds if not thousands of times, and I've gotten the conditional wrong enough times to actually need to revert a change in prod.

I have similar thoughts about .at(). Taking an element from the end of the array is ever-so-slightly error prone. Sure, you won't make a mistake this time, or the next time, but write it a hundred times, or a thousand, and I bet a bug will slip in. It's darn near impossible to get `.at(-1)` wrong, however.

beaconstudios10• 5 years ago

That's actually a pretty reasonable argument, the 'length - N' form is actually quite prone to off-by-one errors so .at might help there.

NicolaiS• 5 years ago

Indeed, and as others have stated it is really hard to allow `[-1]` without breaking old code.

Also: `[1, NaN, "hi"].indexOf(NaN)` is -1 but `.includes(NaN)` returns true as expected.

alerighi• 5 years ago

Except you would never get to use this method, because it will take years for all browser vendors to implement it, and even then, you still have a number of users that use for a reason or another Internet Explorer.

You need to use a transpiler (like Typescript), but at this point, there no reason to implement that in the language, a transpiler can implement the feature by simply adding the method to the prototype of the object, like this:

    Array.prototype.at = function (i) { return i < 0 ? this[this.length + i] : this[i] }

112358132134552• 5 years ago

This will be handy for a multitude of string libs, for example string diffing (fast myers diff, ...)

112358132134552• 5 years ago

Oh actually I thought '\u{1f4a9}'.at(0) === '\u{1f4a9}' but np, after reading the docs, it's just like charAt except for negative indices

Quite disappointed so, my parent comment doesn't stand too

cpeterso• 5 years ago

The MDN documentation for Array.prototype.at is easier to understand than the linked proposal: https://developer.mozilla.org/docs/Web/JavaScript/Reference/...

z3t42• 5 years ago

Im a JS veteran, and not a single word in the article made any sense to me.

Stage 3 Proposal: Array.prototype.at

Related Stories