TypeScript should infer relationship between function argument types from overloads

[paskozdilar]

🔍 Search Terms

typescript function argument conditional type overloads automatic infer

✅ Viability Checklist

• 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, new syntax sugar for JS, etc.)
• This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

It would be nice if compiler could use the overloaded function declarations to automatically infer information about types in the implementation, to avoid unnecessary type checking.

📃 Motivating Example

https://tsplay.dev/w1LKOW

// The compiler forces us to type check the `value` in the implementation...
function Foo(value: number, ok: true): void;
function Foo(value: undefined, ok: false): void;
function Foo(...args: [number, true] | [undefined, false]): void;
function Foo(value: number | undefined, ok: boolean): void {
  var n: number;
  var u: undefined;
  if (ok) {
    n = value; // ERROR: Type 'number | undefined' is not assignable to type 'number'.
  } else {
    u = value; // ERROR: Type 'number | undefined' is not assignable to type 'undefined'.
  }
}

// ...even though the function overloads guarantee that the above cannot happen:
Foo(42, false); // ERROR: No overload matches this call.
Foo(undefined, true); // ERROR: No overload matches this call.

declare var value: number | undefined;
declare var ok: boolean;
Foo(value, ok); // ERROR: No overload matches this call.

declare var args: [number, true] | [undefined, false];
Foo(...args); // No error: arguments are fine

💻 Use Cases

1. What do you want to use this for?

I want to define a function which can receive a union tuple and have an efficient implementation of it.

3. What shortcomings exist with current approaches?

Unnecessary runtime checking required.

5. What workarounds are you using in the meantime?

Runtime checking.

[MartinJohns]

You can do:

function Foo(value: number, ok: true): void;
function Foo(value: undefined, ok: false): void;
function Foo(...[value, ok]: [number, true] | [undefined, false]): void { ... }

[paskozdilar]

That's another workaround, sure, but I have trouble understanding why TypeScript can't infer the case above.
Why does one construct work, but another (equivalent one) doesn't?
Is there some kind of rule I can follow to know in advance when something isn't working, and I should use alternative, equivalent format to achieve the thing?

Sometimes it feels like trying to make TypeScript work with me instead of against me is a game of cat and mouse.

[craigphicks]

That's another workaround, sure, but I have trouble understanding why TypeScript can't infer the case above. Why does one construct work, but another (equivalent one) doesn't? Is there some kind of rule I can follow to know in advance when something isn't working, and I should use alternative, equivalent format to achieve the thing?

It could be (but isn't currently) possible to write

function Foo(value: number, ok: true): void;
function Foo(value: undefined, ok: false): void;
function Foo(value,ok) { ... }

because the necessary info is already in the overloads, as you say. In fact I recently read an old ts issue saying exactly that - I can't find it right it now though. So that part of your issue is a duplicate. Likewise for type checking the implementation.

Here is one way your code could be rewritten to avoid compile errors, yet handle all possibilities safely:

// The compiler forces us to type check the `value` in the implementation...
// function Foo(value: number, ok: true): void;
// function Foo(value: undefined, ok: false): void;
function Foo(...[value,ok]: [number,true]|[undefined,false]): void;
function Foo(...[value,ok]: [number,true]|[undefined,false]|[number|undefined,boolean]): void; // | throws "rangeError"
//function Foo(value: number | undefined, ok: boolean): void; // throws "rangeError"
//function Foo(value: number | undefined, ok: boolean): void {
function Foo(...[value,ok]: [number,true]|[undefined,false]|[number|undefined,boolean]): void {
    if (ok && typeof value === "number"){
        value; // number
    }
    else if (!ok && typeof value === "undefined"){
        value; // number
    }
    throw "rangeError";
}

// ... you wrote these apparently meaning that Foo might be called with rangeError inputs. 
try {
  Foo(42, false); // no ERROR: 
  Foo(undefined, true); // no ERROR: 
}
catch(e){}

// ... you wrote these apparently meaning that Foo might be called with rangeError inputs. 
declare var value: number | undefined;
declare var ok: boolean;

try {
  Foo(value, ok); // no ERROR
} catch (e) {}

// ... you wrote this safe in the knowledge that there is no rangeError inputs so try/catch not needed
declare var args: [number, true] | [undefined, false];
Foo(...args); // no ERROR

There is an ambiguity in your code comment "...even though the function overloads guarantee that the above cannot happen:".
Overloads cannot guarantee that a user will not pass rangeError data. They can only guarantee that a compiler error will be raised. But a compiler error can be a nuisance too - as in your call to Foo(value, ok);.

See #57057 for a proposal to less the verbiage in the final overload. (Additional proposal 2).

You will notice that the overloads have been rewritten entirely in ...[] format, and the others commented out. That because your last statement Foo(...args); gives an error otherwise. That is a bug. #57156

[jcalz]

Duplicate of or strongly related to #13235, #44262, #52478 .

#52478 (comment)

"Re-check the body using each overload signature" turns this into a huge problem [...] we'd need to make big advances in control flow, somewhat fundamental changes to how the language service thinks about the type of a node, and possibly invent new sorts of types altogether.

[typescript-bot]

This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes.