support control flow analysis of tagged template calls

[turadg]

Suggestion

🔍 Search Terms

return never tagged template unreachable code

Related issues:
#32695
#50363

✅ Viability 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, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Control flow analysis detecting unreachable code after a tagged template function call that throws.

📃 Motivating Example

It's a surprise that the same function call does not have control flow analysis when used as a tagged template:

function throws(opt?: any): never {
    throw new Error()
}

function testFn() {
    throws(`reason`);
    
    // @ts-expect-error unreachable
    console.log("is unreachable!")
}

function testTag() {
    throws`reason`;
    
    // ts does not detect that this is unreachable
    console.log("is unreachable!")
}

(playground)

💻 Use Cases

Throwing an exception with a message

Normally this would be something like,

assert(condition, 'explanation');

However for performance reasons we eschew the function call:

condition || Fail`explanation`;

The asserts works but the Fail doesn't. We could work around this by Fail('explanation') but we prefer to be consistent in use of the Fail function. So for our current work-around is to explicitly throw the tagged template.

[fatcerberus]

This is actually two separate issues, one of which is by design. The pattern condition || fail("explanation") simply doesn't work at all, as only top-level function calls affect control flow analysis.

#32695

A function call is analyzed as an assertion call or never-returning call when ...
... the call occurs as a top-level expression statement

[turadg]

Thanks for pointing that out. Is there any issue to track a feature request for condition || fail? If not, would one be welcomed? EDIT: yes, #50739

Do switch case blocks count as a top-level expression statement? Because we also use this instead of break.

[MartinJohns]

Do switch case blocks count as a top-level expression statement?

A switch is not an expression at all.

[mhofman]

The lack of narrowing based on logical expression was previously filed as issue #50739.

We can focus this issue on the lack of control flow analysis through tagged template literal as the following code would show:

function throws(opt?: any): never {
    throw new Error()
}

declare const a: string | null;

function testFn() {
    if (!a) throws(`reason`);
    
    a.charAt(0); // a is correctly narrowed to `string`
}

function testTag() {
    if (!a) throws`reason`;
    
    a.charAt(0); // Object is possibly 'null'. ts(2531)
}

function testFnInSwitch() {
    switch(a) {
        case null: // No fallthrough correctly infered
            throws(`reason`);
        default:
            a.charAt(0); // a is correctly narrowed to `string`
    }
}

function testTagInSwitch() {
    switch(a) {
        case null: // Fallthrough case in switch. ts(7029)
            throws`reason`;
        default:
            a.charAt(0);  // Object is possibly 'null'. ts(2531)
    }
}

Playground Link: Provided

[71]

I have implemented this in 71@de96190, but can't submit a PR as this issue is not in the "Backlog" milestone. Is there any way this could be added to the backlog? The proposed change is fairly minimal, but fixes this issue.

[71]

Gentle ping (sorry) -- would love to submit a PR for this.