3 ms·
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 b
by JimDabell 8y ago
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 8y agoso 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 8y ago> 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'.