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

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.

Commencez par la proposition et examinez la branche stopParameterNeglect, y compris son code et ses tests. Exécutez d’abord les tests existants, puis comparez le comportement de compatibilité des signatures avec la règle proposée concernant le nombre de paramètres. Le travail est terminé lorsque les overloads qui acceptent moins de paramètres ne sont pas sélectionnés lorsqu’un overload compatible accepte davantage de paramètres dans la limite de l’arité du callback, sans casser les tests existants.