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.

Start with the linked TypeScript Playground repro and the overload and assignability behavior described in the example. Done means the compiler performs the proposed checks and reports the unsafe call while preserving the stated runtime behavior.