Suggestion: should non-null assert propagate?

I was wondering whether ! should be taken into account by the dataflow analysis, and I don’t see why it shouldn’t.

It is like a cast that says “this value is not null”, so from this point I guess the compiler could remove undefined/null from future uses.

For example, I use ! to work around #9631, so I have code that looks like (simplified):

protected dataArrayChanged(changes: ChangeRecord[]) {
  // #9631: TS incorrectly infers `change: ChangeRecord | undefined`
  for (const change of changes) {
    for (let i = 0; i < change!.removed.length; i++)
      this.dt.row(i).remove();
    if (change!.addedCount > 0)
      this.dt.rows.add(this.data.slice(change!.index, change!.index + change!.addedCount));
  }
  this.dt.draw();
}

Observe how I added 5 ! to make change not null. The first one could have been enough. After all, once I say “change is not undefined”, there is no reason to assume it could be until I modify the variable again.

// Let's say I know x is not undefined
const x: number | undefined;
// Here x: number | undefined, so x! is required
x!.toString();
// Here x: number because of x! above
x.toString(); // ok

[buola]

@jods4

Precisely because ! is a cast that removed the undefined/null types, it shouldn’t behave differently than any other cast.

What you’re saying is not necessarily ‘I know it is not undefined’ but more ‘I want to treat it as not undefined in this expression’.

In my opinion, this suggestion would be the same as accepting something like this

function foo(): number | number[] { return 3; }
function frob(x: number): void {}

let some = foo(); //some is of type 'number | number[]'
frob(some as number); //we might know it's a number, so we do this. Okay.
frob(some); //If casts "teach about" types, this would not be an error. Currently, it is.

Another problem would be that, when closures are involved, a variable being ‘not undefined’ in one line doesn’t necessarily mean that it will still be ‘not undefined’ in the next line. However, this is a problem of type assertions in general. For example, the following legal code throws because typescript can’t detect that a is undefined, and it can’t really be expected to.

(function (){
    var a: number | undefined = 3;
    var b = () => { a = undefined; };

    if(a) {
        b();
        console.log(a.toFixed());
    }
})();

[ChayimFriedman2]

@pmoleri TypeScript 3.7 introduced assertion functions exactly for this purpose, and they have clearer syntax and no need for redundant !, while your code suffers from huge in-readability because you use the non-null assertion where the operand can be null, and even expected to.