In overload resolution, `any` always matches the first of `true` or `false`, never `boolean`

[dgoldstein0]

Bug Report

🔎 Search Terms

control flow analysis
function overrides

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about it.
• I discovered it on 4.0.7 and verified on 4.0.5 and 4.4.4

⏯ Playground Link

Playground link with relevant code

💻 Code

const nonempty: Function = (s: string) => s.length != 0;

function assert(cond: boolean, msg: string) : void;
function assert(cond: false, msg: string) : never;
function assert(cond: boolean, msg: string) {
    if (!cond) throw new Error(msg);
}

const d = nonempty("foo");
assert(d, "hi");
for (const x of ["a", "b", "c"]) {
    nonempty("bar");
}

🙁 Actual behavior

nonempty is narrowed to never after the assert()
The for loop is labeled as unreachable code in the typescript playground (but not by tsc - going to file that as a separate issue)

It appears that typing nonempty as a Function makes the return any, and that doesn't match the right overload of assert - for whatever reason it always matches the assert(cond: false, msg:string) case which returns never and therefore concludes, erroneously, that the rest of the code is unreachable.

🙂 Expected behavior

expect no errors - the assert(cond: boolean, msg: string): void signature should match and so typescript should not be able to assume code after the assert() call is unreachable. Perhaps the typesafe way to do this would be unioning all the possible return types.

Edit by @sandersn: See #46376 (comment) for a smaller repro

[MartinJohns]

Why do you believe any should favor the first over the second overload? Should it always prefer the first? I don't know the current logic, but given your example I would assume it's the last. Changing this would probably be a heavy breaking change. Picking the last one makes the most sense, as the last one is often the most permissive overload.

How would you pick an appropriate overload without any type information (aka any)?

There's really no reason to type the one variable as Function, you're just throwing away type information.

[dgoldstein0]

There's really no reason to type the one variable as Function, you're just throwing away type information.

totally fair, this example is a minimization from an actual codebase I'm working on. In there, we have an assert function much like above, and the role of nonempty is played by prototype.js's $ function. since there aren't any open source types, we declare const $: Function just to make typechecking work and mean to accept it won't catch all errors. however, inventing errors out of thin air is not something I expect as a consequence of any.

Why am I using prototype in 2021? not by choice, I assure you. That might be the next legacy code battle I decide to fight, but it's not my current one.

Why do you believe any should favor the first over the second overload? Should it always prefer the first? I don't know the current logic, but given your example I would assume it's the last. Changing this would probably be a heavy breaking change. Picking the last one makes the most sense, as the last one is often the most permissive overload.

the order in the example doesn't actually matter - function assert(cond: false, msg: string) : never; is preferred over function assert(cond: boolean, msg: string) : void; no matter what order they appear in - you can see the alternative order with this ts playground.

How would you pick an appropriate overload without any type information (aka any)?

Excellent question... I'm not sure about parameter types, but for return type I'm thinking you could Union the ReturnType<> of all matching overloads. Though I'm guessing there's not much precedent for this.

[DanielRosenwasser]

So originally I was going to say

this is unfortunate, but I think it's working as intended. My advice is either

1. Add a type assertion on the any value (you probably already did this)
2. Add a signature of assert that specifically takes any.

but this is weird and I want to understand it first.

Here's something I found strange

declare function doThing(cond: boolean): "boolean";
declare function doThing(cond: false): "false";
declare function doThing(cond: true): "true";

declare const d: any
var a = doThing(d)

Here a is "false", which means it passes the first overload, but it's not just selecting the last. any has some special behavior in overload resolution due to an initial subtype pass, but I think there's something else going on. Any clues @ahejlsberg?

[IllusionMH]

Aren't overloads sorted with literal types first false/true and then with regular types boolean?
It definitely works with strings for different events mappings of exact events names and then fallback to broader string type. I would assume same is true for boolean and literals.