5 ms·

yes that is obvious - my point was that the functionality is minimal. with guards: const at = (arr, i) => { if(!(Array.isArray(arr) && typeof i === '

yes that is obvious - my point was that the functionality is minimal. with guards: const at = (arr, i) => { if(!(Array.isArray(arr) && typeof i === 'number')) { throw new Error('invalid arguments'); } // same as before }; you wouldn't just commit a single-line function in your code. But there are 10,000 micro-functions that could be in the core of JS. Why bother to add this, especially if it's so easy to implement? There are surely better things the JS committee could be putting their time towards, like providing functionality that is presently lacking in JS (maybe they could finally get around to advancing the pipe operator through the TC stages).

Osiris 5y ago
Your number guard is insufficient. NaN, infinity, 2.23 are all Number but not supported values for the function. This goes to show that it's NOT trivial to implement in a robust way.
- beaconstudios 5y ago
  It is trivial. It requires a few more lines than my example, but my example was intended to show the core use case. All I'm getting in replies is nitpicking about my example case... Can't you just assume when reading that I know how to write some simple guard statements? It's hardly rocket science.
  - claytongulick 5y ago
    Because it is such a common case? To invert your argument, why would you want millions of developers to have to waste their time writing this sort of thing for such a common need? Yes, it's clear that you could write the function correctly. Could everyone? What about bugs that aren't obvious? The runtime errors that result? Why would we want to waste so much developer time and effort globally, when we can just add .at() to the language?
- lhorie 5y ago
  If we're going to nitpick, those are actually all valid values for `arr[i]`... (though, to be fair, they don't exactly do what one might necessarily expect)
borschtplease 5y ago
I want you to look at some other languages beside javascript. Take a look at Swift or Ruby. Compared to them it feels like 60% of js code is boilerplate. 200 lines of js can be fit in 60 lines of Swift. All because js stdlib is just sucks. I’m tired of this silly ‘someArray.length ? someArray[someArray.length - 1] : null’, I want just ‘someArray.last()’

Osiris 5y ago

Your number guard is insufficient. NaN, infinity, 2.23 are all Number but not supported values for the function. This goes to show that it's NOT trivial to implement in a robust way.

beaconstudios 5y ago
It is trivial. It requires a few more lines than my example, but my example was intended to show the core use case. All I'm getting in replies is nitpicking about my example case... Can't you just assume when reading that I know how to write some simple guard statements? It's hardly rocket science.
- claytongulick 5y ago
  Because it is such a common case? To invert your argument, why would you want millions of developers to have to waste their time writing this sort of thing for such a common need? Yes, it's clear that you could write the function correctly. Could everyone? What about bugs that aren't obvious? The runtime errors that result? Why would we want to waste so much developer time and effort globally, when we can just add .at() to the language?
lhorie 5y ago
If we're going to nitpick, those are actually all valid values for `arr[i]`... (though, to be fair, they don't exactly do what one might necessarily expect)

borschtplease 5y ago

I want you to look at some other languages beside javascript. Take a look at Swift or Ruby. Compared to them it feels like 60% of js code is boilerplate. 200 lines of js can be fit in 60 lines of Swift. All because js stdlib is just sucks. I’m tired of this silly ‘someArray.length ? someArray[someArray.length - 1] : null’, I want just ‘someArray.last()’