strictNullCheck should detect unreachable default values and code after nullish operator

Suggestion

Using strictNullCheck should allow detection of code that isn't supposed to be reached according to type analysis

🔍 Search Terms

strictNullCheck unreachble nullish default value

✅ 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.

Yes, especially "Statically identify constructs that are likely to be errors."

⭐ Suggestion

This assumes that it is desired to detect errors with unreachable code due to type analysis (see microsoft/TypeScript-Website#1604 ).

With strictNullCheck turned on, some code that is meant to be unreachable and thus an error is not flagged.

📃 Motivating Example

The = 42 below is unreachable (playground) and is the sign that some code is likely to be an error, but nothing is flagged

class Example {
  foo({
    x = 42
  }: {
    x: number
  }) {
    return x
  }
}

Either the declaration should be changed to x?: number, or the default should be removed.

Another example (thanks to @jcalz) using the nullish operator.

function foo(x: number) { x ??= 42 }

Again, it would be helpful if an error or a warning would be raised as that code seems clearly to be a mistake.

Start by reproducing the two motivating examples with strictNullCheck enabled: the destructured x = 42 default and x ??= 42. Determine the intended diagnostics for unreachable defaults and nullish assignments, then use the existing TypeScript compiler test suite to verify both cases and their done-state behavior.