Don't allow falsely discarded parameters when determining overloaded signature compatibility

[RyanCavanaugh]

Motivation

Libraries such as Knockout use overloaded functions, for example:

var x = new MyKnockoutModel();
console.log(x.customerName()); // string
x.customerName('bob'); // OK
x.customerName(42); // Error, 42 is not a string

We can model these in TypeScript:

interface KnockoutElement<T> {
  // Getter
  (): T;
  // Setter
  (value: T): void;
}

However, these overloads turn out to not be safe when used in callbacks. For example:

function readFile(finished: (contents: string) => void) { /*... */ }
var ko: KnockoutElement<number>;
readFile(ko); // No error, but passes a string to a number-expecting setter!

This is because we look at all the candidate source signatures, reject the (x :number) => void signature for having an incompatible type, and accept the () => T signature because it has fewer parameters (an acceptable variance).

This behavior does not map to any actual runtime behavior. The invoker's side might check the .length property of the function to determine what kind of arguments to pass, and the invokee's side might check arguments.length to determine which overload was intended, but the invoker cannot tell what the expected parameter type of the function is, and the invokee reasonably expects to be called with the correct type given a certain arity.

Proposal

As an example, if a callback declaration says it’s going to invoke f with two parameters, we should not consider overloads of f which take zero arguments if an overload with one or two arguments exists.

In 3.8.3 / 3.8.4:

M is a non-specialized call or construct signature and S’ contains a call or construct signature N where […]

Change to

M is a non-specialized call or construct signature and S’ contains a call or construct signature N where no other call or construct signature in S’ has more parameters than N but not more than M, and […]

Analysis

A sample implementation of this rule breaks no existing tests. Check stopParameterNeglect branch for code/tests.

[RyanCavanaugh]

Approved in last week's design meeting. Need to rebase the branch and re-validate against test suites.

[shevchenkobn]

I noticed similar issues in #50018 and I tried to analyze the way proper function type "inheritance" would work. In that issue I came up with algorithm which I would like to present here:

---

extends for functions.

Let's say there is an expression F1 extends F2, where F1 and F2 are function definitions (regardless if they are inline, type or interface).

For simplicity let's ignore rest parameters and any non-function properties on F1 and F2. Also, for type matching let's consider optional and default parameters as required, but with type T | undefined, where T is the original type of a particular optional or default parameter.

Several steps are followed (algorithm exit with result is in bold):

1. The minimum arity of all F1's overloads is less than or equal to the minimum arity of all F2'overloads, otherwise F1 doesn't extend F2.
2. Create an array matches of type Set<F1Overload> of size n, where n - maximum arity of F1, F1Overload - an overload of F1 of arity n. Initialize the matches with empty sets.
3. For all arities n of each overload of F1 create a union cartesianProduct of Cartesian products of all overloads with arity n of F1 with/vs all overloads with arity n of F2.
4. For each pair [F1Overload, F2Overload] from cartesianProduct, where F1Overload - an overload of F1, F2Overload - an overload of F2, n - arity of both overloads, do:
   1. ReturnType<F1Overload> extends ReturnType<F2Overload> (covariant).
   2. For each i-th inferred parameter with type A1 of F1Overload and corresponding i-th parameter with type A2 of F2Overload do:
      • A2 extends A1 (contrvariant).
   3. matches[n].add(F1Overload)
5. If matches contains empty sets, F1 doesn't extend F2.
6. F1 extend F2 with matches being an array of F1's overloads, which actually extend all F2's overloads.

I am not sure, but it seems that the current implementation doesn't consider matches.

---

Type definition to get only matching overloads

Probably, after checking with F1 extends F2, the F1 must be transformed into F1_, which would consist only of all overloads inside matches.

Perhaps, a type like OverloadsOf<Func extends Function, Match extends Function> would be useful. It would return only those overloads of Func, which can be used as all overloads of Match (only overloads from matches array). I am not sure how it can be implemented with type definitions 🤔.