[JimDabell]

Sure, but you're putting a workaround in – there really shouldn't be any need for that no-op arrow function. But you do actually need it in order to drop all but the first arguments.

This is simple, straightforward, and wrong:

    ["1", "2", "3", "4", "5", "6", "7", "8", "9", "10"].map(parseInt)

This doesn't work because map() stuffs a counter into the second argument of parseInt(), which is expecting a radix for its second argument. So the iterations of the map go like this:

    parseInt("1", 0)
    parseInt("2", 1)
    parseInt("3", 2)

…and so on, which obviously gives garbage results. JavaScript is littered with these kinds of weird edge cases. Even your example with the workaround isn't 100% reliable, it's browser-dependent – when you have leading zeros in your strings, some browsers will interpret them as octal, and some won't.

[gear54rus]

so what is your problem with all this? that these functions have both provided a flexible interface for use cases that are not this single one?

[kybernetikos]

> browser-dependent

Language version dependent rather than browser dependent.

It may seem the same (after all, different browsers implement different versions of the language), but it's a bit different, if you say 'browser-dependent' it makes it sound like there is no standard when in fact, the leading zero behaviour hasn't been the case since ecmascript 5. You'll struggle to find a browser in common use that doesn't support at least ecmascript 5. It's as browser-dependent as the array.map function which was added at the same time.

Your example code would never have the leading 0 problem since you're using array.map and array.map didn't exist in the engines that had that leading 0 'feature'.