Live data from Hacker News

Stage 3 Proposal: Array.prototype.at

tc39.es

41–50 of 153 posts

Re: Stage 3 Proposal: Array.prototype.at

#42

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.

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.

Re: Stage 3 Proposal: Array.prototype.at

#43

Earlier quoted context omitted.

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.

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

It's not surprising given that JavaScript was designed and deployed world-wide by C++ developers.

Re: Stage 3 Proposal: Array.prototype.at

#44
post #24

Earlier quoted context omitted.

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.

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?

The web as a platform is the most elaborate and epic showcase at not breaking backwards compatibility in the entire history of computing.

In the face of disasters like Python 2->3 and Apple M1 macs no longer being able to play Starcraft Remastered, the web is an aspirational beacon.

Let’s keep it going.

Re: Stage 3 Proposal: Array.prototype.at

#45
post #35
post #22

Earlier quoted context omitted.

It’s not adding negative indexes, a negative number will index from the end. So [0, 1, 2, 3].at(-2) === 2

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...

Good thing we don't have to stagnate progress just because what we have will never be perfect.

Re: Stage 3 Proposal: Array.prototype.at

#46
post #23

Earlier quoted context omitted.

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.

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

I expect what we’ll end up with is languages like TS supporting a flag to convert all/most index lookups into .at() notation. Or maybe it’ll just be an eslint flag.

I absolutely agree that some metadata at the top of a module enabling behavior like this would be ideal.

Re: Stage 3 Proposal: Array.prototype.at

#47
post #44
post #24

Earlier quoted context omitted.

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?

The web as a platform is the most elaborate and epic showcase at not breaking backwards compatibility in the entire history of computing. In the face of disasters like Python 2->3 and Apple M1 macs no longer being able to play Starcraft Remastered, the web is an aspirational beacon. Let’s keep it going.

Isn't Windows even more epic?

Re: Stage 3 Proposal: Array.prototype.at

#48

const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i]; Why does the core language need to be extended to incorporate this?

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.

Re: Stage 3 Proposal: Array.prototype.at

#49

const at = (arr, i) => i >= 0 ? arr[i] : arr[arr.length + i]; Why does the core language need to be extended to incorporate this?

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.

    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.

Re: Stage 3 Proposal: Array.prototype.at

#50

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.

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