Control Flow Analysis Doesn't Correctly Narrow Types in Unreachable Code After a Return Statement

[hmzakhalid]

🔎 Search Terms

"code after return", "dead code typecheck"

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about Type System Behavior.

⏯ Playground Link

Typescript Lang Link

💻 Code

function find(item: string): void {
    // some logic here
}

function example(items: Map<string, string>): string | void {
    const a = items.get("1");
    return a;

    // The following check ensures `a` is not undefined.
    if (!a) return "No A";

    // Even after the above check, TypeScript throws an error for the line below,
    // indicating that `a` can be undefined.
    const b = find(a); // Error: Argument of type 'string | undefined' is not assignable to parameter of type 'string'.
                       // Type 'undefined' is not assignable to type 'string'.
}

🙁 Actual behavior

When there's unreachable code following a return statement, TypeScript's control flow analysis seems not to correctly narrow the type based on the checks present in the unreachable code.
TypeScript throws an error indicating a can be undefined.

🙂 Expected behavior

Even though the code after the return statement is unreachable, TypeScript should recognize that the check if (!a) ensures a cannot be undefined when passed to find(a).

Additional information and Questions

• Firstly, could you please confirm if this behavior is indeed unintended and not by design?
• If this is an issue worth fixing, could you point me towards the relevant parts of the codebase or any related issues/pull requests that might give me a head start?
• I am eager to take this up and provide a fix. I hope this can be a valuable contribution to the TypeScript community.

[MartinJohns]

Duplicate of #26914.

[hmzakhalid]

Hey @RyanCavanaugh, I see the issue is still open. if it needs to be fixed, I'm very keen on contributing and helping resolve it.
Would it be possible to get some pointers or guidance on where to start or any context from the ongoing discussions on the original issue?

[RyanCavanaugh]

@hmzakhalid this isn't the kind of issue someone unfamiliar with the area would be able to fix

[typescript-bot]

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