Stricter Assignability Checks for Overloaded Functions

Search Terms

function overload, assignability

Suggestion

When a function has overloads, each with a different number of arguments, subtle bugs can occur.

My suggestion is to have extra assignability checks for overloaded methods/functions.
When assigning A to B the algorithm should be,

1. Is A assignable to B under the existing assignability rules?
2. Is A an overloaded function/method?
   1. If it is not, we are done.
   2. If it is, we need more checks,
      1. Does the assignable overload of A have the same number of arguments as B?
         1. If it does, we are done. (Right? Maybe?)
         2. If it doesn't, find all overloads of A with the same number of arguments as B
            1. Is each overload assignable to B? If it isn't, we have a compile-time error

Use Cases

Better type safety. I've been bitten by this behaviour regarding overloaded functions/methods in the past, with far more complicated examples. My general advice to people is to avoid overloads as much as possible/at all cost.

If this hole in the type system is fixed, I may not be so averse to overloads... Or I'll probably find something else to gripe about =x

Examples

The repro below has the following properties,

• Each overload has a different number of arguments
• Each overload has a different return type

function foo(a: number, b: symbol): string;
function foo(a: number): number;
function foo(a: number, b?: symbol): string|number {
  if (b == undefined) {
    return a;
  } else {
    return `a:${a},b:${String(b)}`;
  }
}

function takesNumCallback(callback: (a: number, b: number) => number) {
  const tmp = callback(1, 2);
  if (typeof tmp != "number") {
    throw new Error("wat");
  }
  console.log(1 / tmp);
}

//Allowed during compile-time
//But will throw an error during run-time
takesNumCallback(foo);

Playground

The problem here is that foo (a : number) : number is assignable to (a : number, b : number) => number, because TS assumes foo (a : number) : number will ignore the second argument (b).

However, TS is not considering the other overload that has two arguments and is expecting b : symbol.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Well, it would break TS code for people currently using overloaded functions/methods unsafely.

Comienza con el repro enlazado de TypeScript Playground y con el comportamiento de sobrecarga y asignabilidad descrito en el ejemplo. Se considera terminado cuando el compilador realiza las comprobaciones propuestas e informa de la llamada insegura, preservando el comportamiento de ejecución indicado.