Repository navigation
strictNullChecks blocks safe typeof capture #16108
Description
Sorry if this is a dupe - I tried searching but github's search isn't great.
TypeScript Version: 2.3.1
Code
interface Nested {
child: {
prop: string
}
}
declare function maybeGetNestedValue(): Nested | null
const nested = maybeGetNestedValue()
const child: typeof nested.child = {
prop: 'value'
}TypeScript Playground link
Note: You need to manually enable strictNullChecks under the options for this link. If I enable it and try to share it says the text buffer is too big to share.
Expected behavior: I would expect to be able to use typeof to capture the type of this nested field, since as you can see in the emitted code in the TypeScript Playground link, there is no dereference of the nested field emitted, so the code should always be safe.
Actual behavior: The strictNullChecks flag raises an error because the nested field may be null.
Activity
dylanscott commentedon May 26, 2017
Also note: It appears you cannot use the non-null assertion operator to appease the compiler here.
typeof nested!.childdoesn't appear to even be syntactically valid.aluanhaddad commentedon May 26, 2017
That error message is indeed strange in type position.
What type would you expect the
child variableto have?It cannot be
dylanscott commentedon May 26, 2017
Ah, I suppose it can't. I'm trying to capture the type
{ prop: string }but you're right that I was thinking about it wrong.typeof nested.childisn't well-defined (or maybe it is? maybe{ prop: string } | never). In this case I guess you could just doNested['child'], but that doesn't work if you have further layers of nesting with potentially null fields.aluanhaddad commentedon May 26, 2017
The simplest fix is to create an extra local which is obviously not ideal or, as you need to test
nesteditself before use, you could just test it earlieraluanhaddad commentedon May 27, 2017
Andy (Andrewkraft) (@Andy-MS) right, thank you! I keep forgetting about that syntax. It's definitely the way to go here.
RyanCavanaugh commentedon May 30, 2017
Feels like property access in
typeofexpressions should implicitly be gettingx!.y. Unclear what value there is warning someone about a possibly-nullxin that caseRyanCavanaugh commentedon Jan 30, 2018
Easy PR if anyone wants to grab this
mhegazy commentedon Mar 9, 2018
Discussed this again in #22445. Conclusion, with
NonNullableavailable now with conditional types, the original scenario should be unblocked, no reason to add new rules.So the sample in the OP would look like: