Reject functions with not enough parameters on strict mode

[inad9300]

As is well explained in the FAQ, "functions with fewer parameters [are] assignable to functions that take more parameters."

This is fine to ease the transition from JavaScript, but limits TypeScript's ability to detect errors at compile time. A compiler flag to switch on this check would be an amazing step towards safer code.

This option may also be enabled by the "strict" flag.

[DanielRosenwasser]

So you would be okay with all your callbacks to map requiring 3 parameters? For example

function squareAll(nums: number[]) {
  return nums.map((v, _index, _arr) => v ** 2);
}

[inad9300]

I understand it's inconvenient for some native functions, but if that's the price to pay for detecting mistakes, I'm absolutely OK with it. The trigger of this request was indeed a hidden mistake that took a while to catch up due to TypeScript being too tolerant.

Besides, for custom functions, you can always define optional parameters, which will be very useful in callbacks. In fact, perhaps this is the way all callbacks of native functions accepting them should be declared.

[antoniovazquezblanco]

On top of what @inad9300 has said, you're not obligated to rewrite all your map callbacks because you are not obligated to turn that check on.

[RyanCavanaugh]

you can always define optional parameters,

This isn't what an optional parameter means! If strictly enforced (which we don't because everyone gets it wrong when writing declaration files), an optional parameter in a callback position means "I (the caller) might not provide this parameter", not "You (the callee) are free to ignore this parameter".

you are not obligated to turn that check on.

Of course. The line of discussion here is about whether anyone would turn this flag on in the first place if it caused massive headaches for all built-in array functions. Our hypothesis is "no".

[antoniovazquezblanco]

In my case the answer would be yes. I would turn this flag on to ensure my callbacks are correctly defined and called instead of silently failing.

[RyanCavanaugh]

Can you show an example where a callback was "silently failing" ?

@inad9300 same question - seeing the actual bug you had would be very informative

[inad9300]

This is not best place to pose questions, but since it is relevant for the discussion... Given the following code:

function each<T>(list: T[], callback: (item?: T, index?: number, listReference?: T[]) => void) {
    // ...
}

What do the optional parameters mean here? As I see it, they should mean that I, the caller of each (which is the caller of the callback), am allowed to provide a callback function which does not take any parameter at all, but might also provide a callback that accepts an item, or and item and a number, an so on.

Edit Added missing name for the callback argument.

[RyanCavanaugh]

What you've typed represents a function that acts like this

function each<T>(list: T[], cb: (item?: T, index?: number, listReference?: T[]) => void) {
    // ...
    cb();
    cb(list[0]);
    cb(list[1], 1);
    // etc
}

[inad9300]

OK. It's a bit confusing, but I think I understand. Now, what does it mean for the provider of the callback to declare its parameters as optional? It's completely useless and ignored, as I can see quickly in the playground.

function each<T>(list: T[], cb: (item?: T, index?: number, listReference?: T[]) => void) {
    // ...
    cb();
    cb(list[0]);
    cb(list[1], 1);
    // etc
}

// What is the difference between these two callbacks?
each([1, 2, 3], (item: number) => { })
each([1, 2, 3], (item?: number) => { })

[RyanCavanaugh]

// What is the difference between these two callbacks?

The first one should be illegal given the definition of each, but isn't. This is basically due to historical reasons - people wrote tons of definitions using ? thinking it meant "you may ignore it", and we didn't detect the error due to a bug. If anything were to change here regarding callback arity under strict, it would be to make this an error.

The second one is a "correct" callback for a declared callback type which has optional parameters.

[aluanhaddad]

A function has an interface and a function with fewer arguments can implement that same interface so long as the types of the arguments it provides are assignable

type F = (key: string, value: string) => object;

An example implementation of F could be

const f: F = (key, value) => ({[key]: value});

Another implementation of F is

const g: F = key => f(key, key);

Why is this a problem?

Trying to enforce that a provided callback binds each possible argument feels like trying to depend on the implementation of an interface.

[inad9300]

Thanks for the clarification, @RyanCavanaugh. In my opinion, the separation between normal and strict modes should allow to overcome this kind of history-provoked limitations. That bug should definitely be fixed in strict mode.

@aluanhaddad, for me, it is precisely when I see functions as interfaces when it makes the less sense. If you accept { a: number, b: number }, you cannot provide { a: 2 }. You can however do it when the interface is { a: number, b?: number }. Now we move over to functions and the same doesn't hold. In your example, g is not a valid value of type F the same way { a: 2 } is not a valid value of type { a: number, b: number }. I find totally predictable that "everyone gets it wrong", as @RyanCavanaugh pointed out. It's just inconsistent, isn't it?

[RyanCavanaugh]

I don't understand the claim that g is not a valid F. People write code like let n = arr.map(x => x - 1) all the time. There's no way you can say that code is wrong in any meaningful sense of the word; it is simply refuted by experience.

Again I'd like to see the root-cause bugs here to understand how you had a bug caused by wrong function arity. The only case I can think of is something like writing a comparator function, where it's somewhat implausible that you could write a correct 1-arity function for Array#sort (though you could still write a correct implementation using the arguments object!).

[inad9300]

Of course in the current system g is a valid F, but I find it similar to { a: 2 } being a valid { a: number, b: number }, which is obviously not correct. All I was saying is that this is at least counterintuitive. As you initially implied, ? is tricky to get; I'm still confused by it.

As for the issue @antoniovazquezblanco and me had, we have been trying to reproduce it, without success unfortunately. Our scenario is a bit complex and we simply didn't manage to return things to the state they were in when we had the problem.

But your example is very good already, and I'm certain there are many analogous cases. If you are Array.prototype.sort, you expect a function with the following interface:

type CompareFn<T> = (a: T, b: T) => -1 | 0 | 1

And you better don't pass to it a function that takes only one argument, because it is not going to work. And all the people using ? wrong are most likely relying on the compiler to catch that.

Actually, Array.prototype.map is a similar case. You are not going to map a lot if you provide a 0-argument function, are you? And yet, this is (and should not be, if in strict mode) valid TypeScript code:

[1, 2, 3].map(() => 42)

Please, don't hesitate to refute my arguments. I might be still missing the point, and I'm happy to be proven wrong.