Condition aliasing doesn't capture optional chain expressions

[jakebailey]

Bug Report

🔎 Search Terms

undefined optional chain aliased condition narrowing

🕗 Version & Regression Information

• This is the behavior in every version I tried (from 4.4 onward, when we added aliased conditions).

⏯ Playground Link

Playground Link

💻 Code

interface Foo {
    getValues(): number[];
}

declare const foo: Foo | undefined;

const vals = foo?.getValues();
if (vals) {
    foo; // Foo | undefined
}

const vals2 = foo && foo.getValues();
if (vals2) {
    foo; // Foo
}

if (foo?.getValues()) {
    foo; // Foo
}

🙁 Actual behavior

foo is potentially undefined in the first if block. The assignments fail.

(Added assignments so there's some feedback now that the playground's //^? doesn't work pre-4.6.)

🙂 Expected behavior

foo is narrowed to Foo in the first if block, matching the narrowing in the other if blocks.

[jakebailey]

cc @DanielRosenwasser @RyanCavanaugh @ahejlsberg

Daniel said I should make an issue and ping you all; is this an expected limitation or a bug/oversight?

[RyanCavanaugh]

Looks like an oversight to me

[fatcerberus]

If this is a bug, that would suggest that if one were to write

if (foo?.bar?.baz) {
    /* ... */
}

then all three of foo, foo.bar, foo.bar.baz should be narrowed to be non-nullish. I'm skeptical, because I don't think TS has ever done narrowing of a parent object like this outside of discriminated unions.

edit: Oops. Just realized the bug is that this narrowing does work, just not when the result of the expression is aliased.

[craigphicks]

I had posted an "intro to inference" here as an assist to myself and perhaps someone else who was interested the topic , but it clutters this issue so I am removing it. At least an internal document covering the algorithm would be helpful for maintenance and optimization. I don't see that existing at moment - (am I wrong?). I've learned a lot while doing so I would like to write such a document. Where should it go? @ahejlsberg