Only because map's third provided argument exists. If map only supplied element and index to the callback, this would pass most type checkers I'm familiar with, and would remain just as confusing.
It's both. Silently accepting variadic arguments increases the odds of something like this happening. This case wouldn't have happened without it.
Though as I said in another comment, best-effort parsing was a decision that arose out of the Web ecosystem and its one of the few things about Javascript's language design that can't br blamed on incompetence.
What does this have to do with best-effort parsing?
"Variadic arguments" (really optional arguments with defaults/signature overloading, which is only arguably the same thing) existed long before JavaScript, and, indeed, the web. Optional arguments are also widely considered to be good/useful.
Yes but with mandatory parameters the programmer would be aware parseInt had a radix in the first place if they had used it even once. That's one advantage of mandatory parameters, but there are of course disadvantages.
I'd argue basically everything about mandatory arguments is worse than having edgecases like this.
Honestly, most languages STILL won't catch this, because the typical pattern is to use method overloading to provide multiple signatures if default arguments aren't supported.
> I'd argue basically everything about mandatory arguments is worse than having edgecases like this.
Any sane language having optional arguments is using keys for opt args. That's what common lisp and OCaml do.
In OCaml you would write:
let parse_int ?(radix = `Dec) string =...
val parse_int : ?radix:[`Bin | `Oct | `Dec | `Hex] -> string -> int
and call it like
parse_int "42"
- 42
parse_int ~radix:`Bin "111"
- 7
List.mapi parse_int ["1"]
- Static error: this expression has type `string -> int`
but expected int -> 'a -> 'b
