--strictNullChecks enforcing unnecessary tests

[jice-nospam]

TypeScript Version: 2.0.3

Code
More a suggestion than a bug. I found out that there are a few situations where enabling strictNullChecks results in unnecessary complexity in the code. For example :

if ( myArray.length > 0 ) {
    let o: Object = myArray.pop();
    o.method();
}

Expected behavior:
should compile

Actual behavior:
requires a Object | undefined type and an additional safety test

if ( myArray.length > 0) {
    let o: Object | undefined = myArray.pop();
    if (o) {
        o.method();
    }
}

[jeffreymorlan]

The length check is unnecessary. pop on an empty array returns undefined and leaves the array empty:

let o = myArray.pop();  // o has type Object | undefined here
if (o) {                // type guard
    o.method();         // ok, o has type Object here
}

[Bobris]

Workaround I am using is to help TS with bang:

if ( myArray.length > 0 ) {
    let o: Object = myArray.pop()!;
    o.method();
}

[jice-nospam]

@Bobris Thanks, I wasn't aware of the Non-null assertion operator. I should have read the documentation!

[Bobris]

For random readers: https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript#non-null-assertion-operator
Though I would still like to know if there is plan when this will work automatically.

[mhegazy]

Though I would still like to know if there is plan when this will work automatically.

there is no plans to change how it works. This operator is an escape hatch to force the compiler to forget about the null and undefined in the type if the value is set in call back or inner function that the control flow analysis does not have access. it is the user saying "trust me, i have initialized this already".

[Bobris]

@mhegazy I meant original question, if TS will know that pop does not return undefined if length > 0.

[mhegazy]

oh.. i see. that is gonna be tough.

[kitsonk]

if TS will know that pop does not return undefined if length > 0

That requires all sorts of codependent relationship of properties and a system for expressing them. Just because an Array has a property that is .length and and if that .length is a positive integer, then certain methods of Array will return their type, versus undefined, that doesn't mean that is true of other objects that have length. Also, Map and Set have the property .size but no .length, so you would have to write a rule for that as well and express all of that in the return typings.

Do you have a proposal for how one could express that? Even if there was a syntax like that, really would it be worth the effort?

Maybe something crazy like:

interface Array<T> {
    pop(): this.length > 0 ? T : undefined;
}

But CFA would have to keep a lot more in mind at every code point, just in case it was needed for evaluation. It would also broaden significantly the complexity of the state model I assume as well, because it wouldn't just be a handful of types tracked, but essentially an unbounded level of literal types for evaluation.