This likely occurs because the rule has logic to determine if the non-null assertion is a "definite assignment" assertion.

Variables can be declared without a nullish type and not be assigned a value. When we inspect the type at the usage it is a non-nullish type. So a non-null assertion looks unnecessary, but it is actually necassery (removing it would be a type error).

@bradzacher

This likely occurs because the rule has logic to determine if the non-null assertion is a "definite assignment" assertion.

Variables can be declared without a nullish type and not be assigned a value. When we inspect the type at the usage it is a non-nullish type. So a non-null assertion looks unnecessary, but it is actually necassery (removing it would be a type error).

Oh, fascinating...... and a quick look in the code shows also that you've thought about this before, too :) microsoft/TypeScript#31124

Just to be clear, though, which of the following do you mean by your response?

1. This behavior is a necessary tradeoff in order to handle let x!: number-type cases correctly
2. This behavior is a fixable bug, that is probably caused by incorrect logic designed to handle let x!: number-type cases
3. This behavior may or may not be fixable, investigation would be needed. A good starting point would be to look at the code that is designed to handle the let x!: number-type cases

Cases like this is what I'm referring to

let x: number;
x!.toFixed();

playground

If you remove the non-null assertion then you get a TS error. This sort of code looks bad but there's usually a callback function between the assignment which TS's can't track.

Gotcha, yeah, so that seems clear to me, since that's literally a (tricky) case of a necessary nonnull assertion. Do you think, though, that that pattern would apply to variables declared with the declare keyword? I can't quite picture how it would translate.

Based on some quick testing - no it does not apply to declare'd variables because those variables have no "potentially unassigned" state.