Optional chaining discards contextual type data about typescript HOT 4 CLOSED

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.

from typescript.

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;
}

from typescript.

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.

from typescript.

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

from typescript.