Why [“1”,“2”,“3”].map(parseInt) yields [1, NaN, NaN] in JavaScript (2011)
wirfs-brock.com
wirfs-brock.com
> Looking at the specification of parseInt you should notice that it is defined as accepting two arguments. The first argument is the string to be parsed and the second specifics the radix of the number to be parsed. >...the function that is passed as the first argument to map as the callbackfn. The specification says, “the callbackfn is called with three arguments: the value of the element, the index of the element, and the object that is being traversed.”
> Array.prototype.map passes the element's index as the second argument to the callback, and parseInt accepts an optional second argument as the radix (base).
> Using the index as the radix yields a nonsensical result.
In other words, you could do:
parseInt("1");
parseInt("1", radix: 16);
parseInt("1", 16);
Edit: And I'm not talking about named arguments as an option (lots of languages provide this, though not JavaScript). I mean required, where the very concept of argument order (except for first) doesn't even exist.
Passing the index and object for .map() can come in handy sometimes, so I understand the motivation for including it. But with named arguments, they could be passed as something like "_index:" and "_obj:", rather than getting slotted in as an arbitrary [1] and [2], where they can be misinterpreted as other parameters (like "radix").
The article describes the situation in detail, but `parseInt` is called three separate times (its first argument in each call is `"1"`, then `"2"`, then `"3"`, as you'd expect with any array-mapping operation). The weirdness arises because `.map` always passes more than one argument to the callback (and `parseInt` accepts more than one parameter). This happens even when the array has only a single element, it's just that the first call (`parseInt("1", 0, ["1"])`) happens to have the same return value as `parseInt("1")`, so you only notice the weirdness with the later elements.
> (…) it is much more verbose and arguably less elegant.
Article is from 2011 and referencing ES5. With ES6 arrow functions we can make it shorter and more elegant:
["1","2","3"].map(value => parseInt(value))
["1","2","3"].map(n => parseInt(n)) ["1","2","3"].map(parseInt); // returns [1, NaN, NaN]
Arrow functions are graceful and preferred precisely because of this. Passing a naked function reference like that to map is frowned upon where I work, and your PR would not get approval because it is risky for the reasons pointed out in this article.
TL;DR - use modern JavaScript features to make your code more readable and more reliable.
The article is from 2011, and I'm not even sure arrow functions were in the spec at that time. Nowadays the best practice would be: `["1," "2", "3"].map(maybeNum => parseInt(maybeNum))`
> ["1","2","3"].map(Number)
[ 1, 2, 3 ] [
-1, NaN, // could be better
1, 2, 3, 4, 5, 6, 7, 8, 9, // ok a little bumpy at the start but now we're cookin'
11, 13, 15, 17, 19, 21, 23, 25, 27, 29, // not great not terrible
42 // dang
]
Pretty sure the Number constructor was made to get you around this. map(Number) does what you would expect.
Map passes 3 parameter to the mapped function, the second one being an index, and parseInt accepts a second optional argument as radix.
be explicit:
["1","2","3"].map(function(x){return parseInt(x,10)})
https://github.com/microsoft/TypeScript/wiki/FAQ#why-are-fun...
By all means, make an extended mapE function that passes all kinds of things like position in the input iterable, a reference to the iterable, a reference to an at-first empty “memo” object that will be discarded at the end of the map call, etc etc.
C++: https://en.cppreference.com/w/cpp/string/basic_string/stol
Java: https://docs.oracle.com/javase/8/docs/api/java/lang/Integer....
C#: https://learn.microsoft.com/en-us/dotnet/api/system.int32.pa...
But they don't have implicit null/undefined for unspecified parameters, and afaik the map's in these languages do not provide additoinal parameters.
Having also written a book about things to look for and abhor in an interview, I consider this question a strong red flag.
I think it would be to say that [...].mapBETTER(argFunk) calls its arg-function with just a single argument. The rest of the useful ("optional") arguments should be passed by binding "this" to the array of them.
If bind() fails because the function was already bound, should throw an error.
But this brings me to my pet-peeve: Why can't I map over Objects (other than Arrays)?
It's part of the core semantics of the language:
function f() {
}
function f(a, b ,c) {
}
function f() {
let a = arguments[0]
let b = arguments[1]
let c = arguments[2]
}
JS interfaces are designed with the flexibility and semantics of the language in mind (no surprise there, really) and thus try to cover most use cases. If you don't need the index or the reference to the array in your function, ignore them (e.g. by using map(function(v) { ... })). Passing a function that actually supports more than one argument is by all accounts a layer 8 error and not a fault in the spec of map() IMO.
You could just as well argue that it's bad for parseInt() to accept one or two arguments instead of explicitly requiring both. You'd have to try and convince me why one is perfectly fine while the other is not. You can of course argue that both specs are crap, that'd at least be consistent :)
I'm guessing those quotes were supposed to be " rather than “ and ”.
No other language does this.
function fn() { }
function fn(a, b, c) { }
JS has this semantic and the interfaces are designed with that in mind.
Take C# for example. There is a List<T>.ForEach() function that passes the value to the delegate. Fine. But what if I require the index as well? I can't use List<T>.ForEach() in that case, because ignoring extra arguments is not part of C# function call semantics.
The interface of map() has been designed to be as flexible as possible to cover use cases outside of just passing the current value. This matches perfectly with JS function call semantics that allow any number of arguments by default.
Why doesn't parseInt() *always* require two parameters? Why is one design decision "strange and unique" (e.g. map() passing 3 arguments) while the other (parseInt() accepting one or two arguments) is perfectly fine? I also would be careful with citing the STL as being sound when it comes its interface design :)
JS is different from other languages - big whoop. The same complaints about seemingly strange design decisions can be made for any sufficiently old and widespread language - JS isn't unique in this regard.
There actually annoying strangeness in other things, e.g. confusing type conversions in places (e.g. ("" == false) === true; [1, 2, 3] + [4, 5, 6] === "1,2,34,5,6"), which is why "==" should never be used if you want to retain your sanity.
The interfaces and standard functions, however, are as offensive or inoffensive as those in most other languages.
More specifically, you could in C89 but it was removed because it's a bad feature.
Every language that supports default and variable arguments does this. This includes Python, C, and C++ and has absolutely zero to do with "loose typing" in this case.
> help(int)
class int(object)
| int([x]) -> integer
| int(x, base=10) -> integer
> list(map(int, ["1", "2", "3"]))
[1, 2, 3]
>>> def to_int(a, b):
... return int(a, base=b)
...
>>> list(map(to_int, ["1", "2", "3"]))
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: to_int() missing 1 required positional argument: 'b' def to_int(a, b):
...
def to_int(*args):
...
function fn(a, b) {
comnsole.log(a, b)
}
function fn() {
const a = arguments[0]
const b = arguments[1]
console.log(a, b)and that's what people seem to struggle with and argument over for whatever strange reason.
But you can't!!!
> Every language that supports default and variable arguments does this.
Python:
map(float, ["1", "2", "3"])
No equivalent syntax.
C++
std::vector<std::string> a = {"1", "2", "3"};
std::vector<int> b;
std::transform(a.begin(), a.end(), std::back_inserter(b), std::stod); # compile error
Good, bad? IDK, that's subjective. But unique? Certainly.
If you ever, like at all, had the pleasure of using any Python library without type hints - past iterations of numpy and in particular matplotlib come to mind - you'd be blown away by the amount of
def some_function(*args, **kwargs)
Also C does have equivalent syntax, namely variadic functions in combination with function pointer arguments. You can design all kinds of crazy interfaces with that, too, which will exhibit strange and unexpected behaviours if used incorrectly. Heck, name a single C noob who didn't cause a segfault while trying to read a number using sscanf().
When it comes to stdlib interface design, C is actually much more offensive than JS :) strtok() comes to mind. More footguns than stars in the sky just in that innocent seeming function alone. And don't even get me started with the C++ STL...
So no, it's not just JS that makes design choices that seem odd and unintuitive - you'll find them in every language that is actually in widespread use and "battle tested". It's funny to me how some people try to single out JS in that regard, even though it's in no way special when it comes to this.
While each of those flexibilities can be useful, they interact in annoying ways. The fact that map passes three arguments but is often used as if it was passing one, and that parseInt accepts two arguments but is often used as if it accepted one makes it very easy to make this mistake.
This just goes to show how one can use a language without actually understanding its core semantics. Additional arguments aren't "discarded" at all: they're still available to the called function in via `arguments`, they're just not required to be assigned a name in the function signature.
Basically, a Javascript function fn() declaration is equivalent to Python's def fn(*args): declaration and you have the option to assign a name to positional arguments. Any named positional argument that is not provided by the caller simply leaves the argument uninitialized, i.e. undefined.
It's a core concept of the language and I'm always puzzled when non-beginners struggle with this. That's also a very good reason to not use vanilla Javascript at all and skip straight to TypeScript and its brethren instead.
This issue is all about the number of arguments problem, and TypeScript (in cases like this) won't flag that problem. Which is something I think it should.
If you manually unroll the "map" and call parseInt() explicitly with the same arguments that map() calls parseInt() with, TypeScript will flag that. But not when map() is in the picture.
I understand why they chose to do that, but I still disagree with it.
error TS2345: Argument of type '(string: string, radix?: number) => number' is not assignable to parameter of type '(value: string, index: number, array: string[]) => number'. Target signature provides too few arguments. Expected 3 , but got 2.
console.log(["1","2","3"].map(parseInt));
I'm curious - have you been using this for long? Have you noticed any code which this flagged and which you thought it was being too strict? I feel like I would want this flag on all of the time, but I'm curious if there are edge cases that I have not considered but maybe you have experienced.
If I do not want to change existing code to add parameters for each callback I use trick bellow : type JavaScriptCallback< T extends (...args: any) => any, P = Parameters<T> > = P extends [...infer Rest, infer _Last] ? ((...args: Rest) => ReturnType<T>) | JavaScriptCallback<T, Rest> : T;
interface Array<T> { forEach( callbackfn: JavaScriptCallback<(value: T, index: number, array: T[]) => void>, thisArg?: any ): void;
map<U>(
callbackfn: JavaScriptCallback<(value: T, index: number, array: T[]) => U>,
thisArg?: any
): U[];If you post old news, it's customary to say so.
Eg, from dang, the moderator:
https://news.ycombinator.com/item?id=36398290
https://news.ycombinator.com/item?id=36366875
Etc
https://hn.algolia.com/?dateRange=all&page=0&prefix=true&que...
Easy fix too: ["1", "2", "3"].map(i => parseInt(i))
map(some_fun, iterable, *iterables)