Is this a regression in control flow-based type analysis for --strictNullChecks?

[seanpoulter]

TypeScript Version: 2.9.2

Search Terms: typeof undefined guard property strictnullchecks

Code

With --strictNullChecks:

const obj: { [key: string]: string | undefined } = {}

const withAssignment = (key: string): string | null => {
    const value = obj[key];
    return typeof value === 'undefined'
        ? null
        : value;  
}

const withTernary = (key: string): string | null =>
    return typeof obj[key] === 'undefined'
        ? null
        : obj[key];
// Type 'string | null | undefined' is not assignable to type 'string | null'.
// Type 'undefined' is not assignable to type 'string | null'.

const withIf = (key: string): string | null => {
    if (typeof obj[key] === 'undefined') {
        return null;
    } else {
        return obj[key];
        // Type 'string | undefined' is not assignable to type 'string | null'.
        // Type 'undefined' is not assignable to type 'string | null'.
    }
}

Expected behavior:

• Just like the example in the docs but with an undefined instead of a string.
• No error.
• No additional explicit check.
• The property does not change in this simple statement so the type assertion should be OK.

Actual behavior: 😓

Playground Link:
http://www.typescriptlang.org/play/#src=...

Related Issues:

• Control flow doesn't recognise undefined check #12600
• CFA issue #12457

[RyanCavanaugh]

See #11483 / #10530

[seanpoulter]

Thanks for the speedy reply @RyanCavanaugh. Since this is the same as #11483, how is it different than the docs on control flow based type analysis? Does that performance hit come from checking if the property access/getter modifies the object?

I'd like to propose two actions:

1. Can we add this to the docs and how do we get that going? This should be as accessible and well documented as the CFA docs for typeof x === 'string. No one else should have to waste their time with this.

2. In #11483 you said:

   Since it should almost always be possible to write const j = list[i] instead, this shouldn't be too burdensome.

   That wouldn't pass code review in the large functional-inspired React/Redux repo I with. Is there any way to opt-in to this check? How do we get that going?

[RyanCavanaugh]

how is it different than the docs on control flow based type analysis? Does that performance hit come from checking if the property access/getter modifies the object?

The difference is x.y vs x[expr].

Notice that CFA works perfectly fine when the keys are static, e.g. if (a.b.c.d) { a.b.c.d.toString() } is OK. The issue is when the key is computed (obj[key]) because now we go from a static lookup of variables + properties we already know about to an infinite matrix of obj vs key, plus the associated cost of determining whether or not key has been mutated between accesses.

1. We'd take a doc PR to improve that (maybe a section about arrays / indexed access?) - https://github.com/Microsoft/TypeScript-Handbook

2. obj[key]! will remove null / undefined from the type

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.