-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Incorrect narrowing on partial of discriminated union #55578
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I think what’s happening is there are two separate narrowings going on here: one for In In So in the I have a feeling this is a known design limitation, but I’m not 100% sure. |
I'm not sure I follow you 100% but look at the following snippet. It seems like type Asdf = {
type: "asdf";
asdf: 123;
};
type Qwer = {
type: "qwer";
qwer: 123;
};
type PartialUnion = Partial<Asdf> | Partial<Qwer>
type TypeNarrowedPartialUnion = (Omit<Partial<Asdf>, 'type'> & Pick<Asdf, 'type'>) | (Omit<Partial<Qwer>, 'type'> & Pick<Qwer, 'type'>)
const blah: PartialUnion = null as any;
if (blah.type) {
//Conceptually, blah should now be of type TypeNarrowedPartialUnion but this errors :(
const test1: TypeNarrowedPartialUnion = blah;
if (blah.type === "asdf") {
const test2: Partial<Asdf> = blah; //Huzzah!
} else {
const test3: Partial<Qwer> = blah; //Errors :(
}
} |
That’s even farther afield from how narrowing works in TypeScript—this second example is definitely working as intended / design limitation. Only unions are narrowed by property checks, and they only filter out constituents. The only time checking a property affects narrowing of the object type that property was accessed on is when that property is a discriminant of a discriminated union. When you check |
But it seems like after checking Am I seeing things incorrectly though? I've been wrong before on my set theory reasoning, but the transformation like I described truly does seem like the most logical thing to do. |
That would be #42384 and is a whole different can of worms. Type narrowing currently only works by eliminating entire constituents of a union, and that process is atomic (there are no intermediate states). |
I think that reasoning is sound; I’m only saying that it’s very different from how TypeScript works. Narrowing a union only filters constituents. |
Ah yeah, I came across that issue when I was looking for duplicates, but I disregarded it because when I read “type guard” I thought it was referring to user-defined type guards, which is a very different narrowing path. This does look like a case of that issue. |
I tend to think of "type guard" as the thing that actually induces narrowing (an |
Huh, going only by |
This issue has been marked as "Duplicate" and has seen no recent activity. It has been automatically closed for house-keeping purposes. |
🔎 Search Terms
Googled "partial discriminated union typescript not narrowing correctly"
Searched repo github issues "discriminated unions partial narrow"
Nothing showed up that looked relevant.
🕗 Version & Regression Information
5.2.2
⏯ Playground Link
https://www.typescriptlang.org/play?#code/C4TwDgpgBAggzgEwGZQLxQN4CgpVJALigCIBDRJYgbhynOSIEYAmAZhoF8at9oBFAO4QATmky1eRYgEchw6rVkimbTtwDGAewB2cYFABGAG1IALIgAVSw4AEtSRgDzxkUAD5RBIgHxjtAVyMjOjg6bRBuWxQACgBCYzMAOl4ASnFcAHoMhNMoW1CIAFswUChNAwArCHVgLA4oCCM4aCioaJzk8GhUHpJ6SjTsTOyTXPyylF5YCjqGpughqCycqDhTTUCEQ2hNSa7POVoOpWEqJYyAUWFhTWE4WLqgA
💻 Code
🙁 Actual behavior
blah.qwer
throws a compiler error.🙂 Expected behavior
blah
is not narrowed as it should be. The first if condition verifies that the type is not undefined. Therefore by the timeblah.qwer
is accessed, we should be able to have narrowed the type correctly down to Qwer.Additional information about the issue
No response
The text was updated successfully, but these errors were encountered: