3 ms·

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,

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.

tomxor 7y ago
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.
- horsawlarway 7y ago
  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. parseInt(in) parseInt(in, radix)
  - ernst_klim 7y ago
    > 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
happytoexplain 7y ago
Precisely - this is an API design failure, pure and simple. Not a problem with typing, optional arguments, etc.
- wutbrodo 7y ago
  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.
  - zbentley 7y ago
    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.

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.

tomxor 7y ago

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.

horsawlarway 7y ago
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. parseInt(in) parseInt(in, radix)
- ernst_klim 7y ago
  > 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

happytoexplain 7y ago

Precisely - this is an API design failure, pure and simple. Not a problem with typing, optional arguments, etc.

wutbrodo 7y ago
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.
- zbentley 7y ago
  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.