Repository navigation
Is this a regression in control flow-based type analysis for --strictNullChecks? #25109
Description
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
undefinedinstead of astring. - 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:
Activity
RyanCavanaugh commentedon Jun 20, 2018
See #11483 / #10530
seanpoulter commentedon Jun 20, 2018
Thanks for the speedy reply Ryan Cavanaugh (@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:
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.In #11483 you said:
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 commentedon Jun 20, 2018
The difference is
x.yvsx[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 ofobjvskey, plus the associated cost of determining whether or notkeyhas been mutated between accesses.We'd take a doc PR to improve that (maybe a section about arrays / indexed access?) - https://github.com/Microsoft/TypeScript-Handbook
obj[key]!will removenull/undefinedfrom the typetypescript-bot commentedon Jul 5, 2018
Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.