If you know...

.filter(a => a)
🤦‍♂️

"I'm calling cops mother fucker".split("").map(parseInt).filter(a=>a).reduce((a,b) => a+b).toString().split("").reverse().join("")

window.parseInt is not a function

if the answer is not sex , then i am not going to open a browser and type all this shit

It's NaN, isn't it

@dotenvironment Oh it's definately not sex. But it depends who you ask.

@Lensflare .map(parseInt) is worse. Index is used as radix 🤦‍♂️

@hjk101 the joys of currying combined with optional parameters.

@lorentz in JS, every parameter is optional.

@Lensflare What bugs me especially is that this would probably work in Typescript as well. First-class functions are marched purely by type, so if a caback fits it sits.

I wonder how unintended argument aliasing can be solved with language design. Sure abandoning fcf or optional arguments is one way to do it, but those are also useful.

Maybe one could force users to specify the arity, perhaps with the function/n syntax Elixir uses, when functions are passed directly by name and neither the argument nor the callee is a locally defined function with no optional parameters

@lorentz why not just forbid to pass functions as values when they have more than one parameter?
Piping multiple values would be an unreadable mess anyway.

@Lensflare That actually makes a lot of sense. If you spell out the arguments, an inconsistency in their order is both very obvious and very easy to fix.