Check truthy/falsy-ness for non-primitives to identify unreachable code

[donaldpipowitch]

Suggestion

In some cases TypeScript can identify unreachable code and throws an error:

const isTrue = true;
if (isTrue === false) {
  console.log('Can never be reached.')
}

In other cases it is currently not possible, but it would be very helpful. (Maybe even with a suggestion what could have been meant - see array example.)

const isArray = ['hello'];
if (!isArray) {
  console.log('Can never be reached. You probably meant `if (!isArray.length) {`.')
}

const isObject = {};
if (!isObject) {
  console.log('Can never be reached.')
}

🔍 Search Terms

• reachable / unreachable
• dead code
• condition
• falsy / truthy
• primitive / non-primitive
• always

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code -> It can break code, but only to show potential bugs.
• 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

Throw errors on unreachable code examples.

const isArray = ['hello'];
if (!isArray) { // error: This condition will always return false. Did you meant to check `isArray.length`?
  console.log('Can never be reached. You probably meant `if (!isArray.length) {`.')
}

const isObject = {};
if (!isObject) { // error: This condition will always return false.
  console.log('Can never be reached.')
}

// OR:
if (isArray) {
} else {
  console.log('Can never be reached. You probably meant `if (!isArray.length) {`.')
}

📃 Motivating Example

This week I saw a colleague which could have found a bug way sooner by introducing such a check. ❤️

💻 Use Cases

Finding bugs.

[sandersn]

This is a good idea, but I don't know how hard it is to create a check that doesn't have too many false positives — or even true positives, to avoid introduces lots of new errors at once. Probably the best thing is to run a prototype on a bunch of real code.

[Zzzen]

Examples of incorrect code for this rule:

function head<T>(items: T[]) {
  // items can never be nullable, so this is unnecessary
  if (items) {
    return items[0].toUpperCase();
  }
}

function foo(arg: 'bar' | 'baz') {
  // arg is never nullable or empty string, so this is unnecessary
  if (arg) {
  }
}

we can run no-unnecessary-condition on real world code.

[DanielRosenwasser]

Keywords: equals equality object objects comparability reference equality value equality semantics