Stage 3 Proposal: Array.prototype.at

Re:Stage 3 Proposal: Array.prototype.at by e1g on Wednesday June 02, 2021 @09:30AM (#27368440)

A function that works in some cases will be a nightmare to debug. The pattern of `indices.map(myObjectArr.at)` is discouraged in JS because it often fails in unexpected ways. For example -

  ["1","2"].map(parseFloat) // works as expected
  ["1","2"].map(parseInt)   // nope

[ Parent | on HN ]

Re:Stage 3 Proposal: Array.prototype.at by antris on Wednesday June 02, 2021 @10:13AM (#27368905)

I've learned ages ago that parseInt cannot be used like this, so it's not a problem for me, but I thought linters already take care of this case? Also I wasn't talking about using parseInt, a broken function like this so I'm not sure what the quirks of old, widely known bad parts of Javascript have to do with using functions as arguments, which is one of the most powerful features of the language.

[ Parent | on HN ]

Re:Stage 3 Proposal: Array.prototype.at by Fatalist_ma on Thursday June 03, 2021 @12:25PM (#27383673)

There's nothing broken about parseInt. The problem is, it can take a second argument(radix), and .map will feed it current item's index as the second argument(and the whole array as the third, but that one will get ignored).

const arr = ['1','2','3']; arr.map(parseInt) is equivalent to: [ parseInt('1', 0, arr), parseInt('2', 1, arr), parseInt('3', 2, arr) ];

[ Parent | on HN ]

Re:Stage 3 Proposal: Array.prototype.at by antris on Friday June 04, 2021 @03:23AM (#27391449)

I know why it works this way. I'm not claiming it has a bugged implementation, I'm saying it's broken by design.

[ Parent | on HN ]