@john it should be possible to detect that kind of trivial case - but in general there are no surprises here

it's been that way for 8 years and has no real impact on portability of code far as I can tell

do anything at runtime would require argument introspection and that's a JS VM perf hole - so not going to do that

Thats what I figured. Thanks @dnolen FWIW, I think I prefer ClojureScript's more permissive version.

@john FWIW, your program is incorrect. (ClojureScript is not intentionally being permissive.)

For example, if we discovered a way to add arity checks at runtime without a perf penalty, then such broken programs would—well—break.

true

It's just "unimplemented" spec, per say, right?

Linters could probably start checking it now at compile time

Well, for whatever branches it can infer

The only thing that worries me is that devs might start passing in extra args to anonymous fns with the expectation that, in the future, they may want to expand their API to handle those extra args, but drop them silently until then. That code would break if stricter arity checking were enforced

yeah our codebase definitely has laziness about e.g. zero-arg inline fns for event handlers (they should have one unused event arg)

The analyzer could be improved to emit arity diagnostics for immediately invoked anonymous functions

It could probably also catch, in general, arity issues with immediately invoked expressions

@john for portable code you won't do that ... because it's not portable and it will be come readily apparent

I haven't seen the case you're talking about personally - most of the cases I've seen are cases of code cleanliness

i.e. passing an extra arg that was dropped, or generally more args than necessary - due to some refactoring

and the only cases where I saw that was when something was used higher order

Yeah, it's never bit me personally, from a code portability POV