Unexpected behavior of property type guard

[doronguttman]

Bug Report

🔎 Search Terms

type guard property

🕗 Version & Regression Information

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

⏯ Playground Link

Playground link with relevant code

💻 Code

interface X {
    foo?: string;
}

declare const x: X;

const a: string = x.foo;
//    ^ expected error: Type 'string | undefined' is not assignable to type 'string'.
//                        Type 'undefined' is not assignable to type 'string'.(2322)


if (x.foo) {
    const b: string = x.foo;
    const c: X & { foo: string; } = x;
    //    ^ unexpected error: Type 'X' is not assignable to type 'X & { foo: string; }'.
    //                          Property 'foo' is missing in type 'X' but required in type '{ foo: string; }'.(2322)
    console.log(b, c);
}

🙁 Actual behavior

A type has an optional property. Using an if assertion statement, TypeScript knows to narrow the optional property when referring to the property itself, but does not know to "narrow" the object as having the property defined.

🙂 Expected behavior

Inside the if assertion, I would expect TypeScript to know that the object has the property defined.

[fatcerberus]

Duplicate of #42384, #31755, and probably a bunch of others. This is a manifestation of a very long-standing limitation.

Interestingly, this very issue is a good case in point for the concern raised here #31755 (comment); it would quickly lead to the compiler synthesizing a bunch of intersections, even from known starting types, which would likely be a performance/memory-pressure issue.

[microsoft-github-policy-service]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.

[microsoft-github-policy-service]

This issue has been marked as a 'Duplicate' and has seen no recent activity. It has been automatically closed for house-keeping purposes.