Detect unreachable code in more scenarios

Search Terms

logical assignment binary expression dead never truthy falsy

Suggestion

Raise compiler errors when the left side of an expression using a logical operator (&& or ||) is unrechable.

Also detect unreachable branches of ternary expressions.

Use Cases

Code that is statically verifiable to be unreahable is almost always a programmer error so TypeScript should detect unreachable code in more scenarios.

Examples

declare const truthy: true
declare const falsy: false;
declare function doSomething(): number

const a = true ? 5 : doSomething(); // error: doSomething is unreachable
const b = truthy ? 5 : doSomething(); // error: doSomething is unreachable

const c = false ? doSomething() : 5; // error: doSomething is unreachable
const d = falsy ? doSomething() : 5; // error: doSomething is unreachable

if (!truthy) {
    doSomething(); // error: doSomething is unreachable
}

if (falsy) {
    doSomething(); // error: doSomething is unreachable
}

Playground link.

---

It would also be nice to expand unreachable code checks to other expressions that are known to be truthy or falsy eg. object/array literals, NaN eg.

declare function doSomething(): number

const a = [1,2,3] || doSomething() // error: doSomething is unreachable
const b = { count: 1 } && doSomething() // error: doSomething is unreachable

if ([1,2,3]) {
    doSomething() // error: doSomething is unreachable
}

if ({ count: 1 }) {
    doSomething() // error: doSomething is unreachable
}

Playground link.

---

Finally, detecting unreachable branches of a ternary expression

declare const truthy: true
declare const falsy: false;
declare function doSomething(): number

const a = true ? 5 : doSomething(); // error: doSomething is unreachable
const b = truthy ? 5 : doSomething(); // error: doSomething is unreachable

const c = false ? doSomething() : 5; // error: doSomething is unreachable
const d = falsy ? doSomething() : 5; // error: doSomething is unreachable

Playground link

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.

This wouldn't be a breaking change in existing TypeScript/JavaScript code

There would be new type errors. The extra safety could be opted into by extending the allowUnreachableCode flag or creating a new flag.

Start by reproducing the logical-operator, ternary, and literal examples in the linked TypeScript Playground links, then trace the compiler's existing unreachable-code checks and the allowUnreachableCode option. Done means the agreed truthy and falsy cases produce compiler errors without changing emitted JavaScript.