Optional chaining discards contextual type data

[dgetu]

🔎 Search Terms

contextual type
optional chaining
subtype reduction
control flow analysis

🕗 Version & Regression Information

• This is the behavior in every version I tried, and I reviewed the FAQ for entries about contextual typing

Optional chaining was introduced in 3.7, and 3.7 has the same behavior.

⏯ Playground Link

https://www.typescriptlang.org/play?#code/JYOwLgpgTgZghgYwgAgGIHt3IN4ChnIBGcUA-AFzICCUUcAngDwgCuAtodAHwDcuAvrgToQAZzDIYmZAF5kLEABMIMUBEXI4otNIA+8pSrWK+wGMgAUAQinpSAOmJQAlDnzIA9B+QRgYABbQktLoUEQkyP5ayABucAA2LCgABgrKqiDqye7CYhIScrYOTnwEXsgAKsii-ugs8RqcyGD0AA4paUaZitkELe2Vss1tEOjmYKXIueLhAF6UFgAelDR0TKwc3Mj6nRnqrjJcsejAGnJLlBUHR3gEBNPo8RD20FChFgBEAcDaWqLAAHMQGwIOBqrV6ooQAByCTCNitYBPD7OSb8PiCIA

💻 Code

interface Foo {
  bar?: Array<number>;
}
const foo = undefined as Foo | undefined;
if (!foo?.bar) {
  // either foo or bar has value `undefined`
  const t = foo?.bar;
  // T should be type `undefined`
  type T = typeof t;
  const baz: (x: Array<number> | undefined) => void = (x: T) => {
    console.error("this assignment shouldn't get past the type checker");
  };
}

🙁 Actual behavior

Type T has type Array<number> | undefined, even though the conditional implies that the value of t is falsy.

🙂 Expected behavior

The compiler should say that foo.bar is undefined in the scope of the then branch of the if statement.

Additional information about the issue

No response

[RyanCavanaugh]

Narrowing doesn't really have a way to represent "this or the other thing must be undefined" in a way that can be propagated around - it has to make a definitive determination about a particular variable.

[dgetu]

I see. So when we have some type guard around a property access, e.g. foo.bar without optional chaining, whatever the type checker infers about bar can only be used to modify the contextual type of foo because foo is the only binding in scope?

If that's the case, I think the "either foo or bar is undefined" assertion can be reframed as "foo has type undefined | { bar: undefined }."

// I'm making the (probably false) assumption that TypeScript can recognize the law of excluded
// middle between Nullish<T> and NonNullable<T>
// `any` is a corner case, but I don't think that it needs to be handled any differently
type Nullish<T> = T & (null | undefined);
interface Foo {
  bar?: Array<number>;
}

const foo = undefined as Foo | undefined;
if (!foo?.bar) {
  type NarrowedFoo =
    // foo is nullish
    | Nullish<typeof foo>
    // xor foo.bar's type is nullish
    | { bar: Nullish<NonNullable<typeof foo>["bar"]> };
  // foo ought to have type `NarrowedFoo`, but this assignment causes a type checker error
  const narrowedFoo: NarrowedFoo = foo;
}

[fatcerberus]

I think the "either foo or bar is undefined" assertion can be reframed as "foo has type undefined | { bar: undefined }."

This would require #42384. Type narrowing operations on foo.bar currently don’t have any effect on the type of foo, except for the specific case of discriminated-union narrowing.

[typescript-bot]

This issue has been marked as "Design Limitation" and has seen no recent activity. It has been automatically closed for house-keeping purposes.