Repository navigation
Variable loses type narrowing when passed as object literal #57013
Description
Activity
Both should be the same result.
Which result is correct?
Both the working version and the currently failing version above should work. They both worked prior to
5.1.6(didn't get into patches leading up to5.1.6so may have been introduced at first release of5.1).Reacted by Ryan CavanaughBisects to #53709
The repro here is an example of the pattern covered by #30779, i.e. relating a source object type to a discriminated union of target object types where no single target type covers the possible set of source values, but the full union of target types do. We have limited support for this pattern, and we handle it by decomposing the source type into a union as long as that union doesn't have more than 25 constituents. For example, in
type A = { kind: "a", data: string }; type B = { kind: "b", data: string }; declare const ab: "a" | "b"; let x: A | B = { kind: ab, data: "hello" };
we decompose the object literal into a union of the two possible values
{ kind: "a", data: "hello" } | { kind: "b", data: "hello" }in order to successfully relate it toA | B.However, we attempt no such decomposition when checking excess properties in object literals. Consider
type X = { kind: "a" | "b", data: undefined }; type A = { kind: "a", data: string }; type B = { kind: "b", data: string }; declare const ab: "a" | "b"; let x: X | A | B = { kind: ab, data: "hello" }; // Error const obj = { kind: ab, data: "hello" }; let y: X | A | B = obj; // Ok
Above, when checking the object literal for excess properties, we first discriminate the target type
X | A | Bby thekindproperty specified in the object literal. It has type"a" | "b", for which we find that onlyXmatches. We then error because thedataproperty is a string that isn't assignable toundefined. Since we only do excess property checking for object literals, there's no error when we first assign the object literal to a variable (but the assignment only succeeds because of #30779).Considering the rarity of this problem and the complexity of incorporating the decomposition pattern into excess property checking, I'm going to call this a design limitation.
This issue has been marked as "Design Limitation" and has seen no recent activity. It has been automatically closed for house-keeping purposes.
🔎 Search Terms
object literal type inference
enum type narrowing
🕗 Version & Regression Information
⏯ Playground Link
https://www.typescriptlang.org/play?ts=5.3.3#code/FAUwdgrgtgBAogN3AFwM4wN7BvAanAOQBUBGGAXhgHJEUYSqAabPQogJgutrGRnabAAvsGABLXiABOAMwCGAYxAwA4uGliFPPlhwgkvAnKggAXPANoA3CwAOUgPa3pyMSFQB+c2H3SbI8UlZRWVtEm1MFl9DYzMLFFQAOjh8YhIbHHsnFzdUc10cGAATOWQ5c1RkKQkAcxYhf1EJZGl5JXjedgiC6OQjE3NtJJS2dgyYLOcpV3d8lhwSsoqq2vrG4GQAT2cO5CJt9y5gAB9VdWqtSxPd8KvT7S6r4AUHMEqYSFhKAFlSgAtEjIADYOBxSAAUv2QAKkcjARQcUHBAEoYAAqegABlRAGp6DZnq93r1+spKJ8YAA+GAAVhgHl2w1SpBgg0sTNGBIA9FyYEQ-mJ0EgpKgxK8YPIxEDUMAskpUKhtOCepZScxMo4pjM8pFCsVSuUYAAib6bXYwAAiBqN9WEyO5vP5gpgwtF4oA7mCANYyl5vPiLORcFUoNV2TU5Wa6wqB8wms0RK1lG04EQNWWOeWKyzgwP20QyCBgBSucVy9zZlDg3pslD7ZyoVEFP2oBxAkCJEE1auWfMiIA
💻 Code
🙁 Actual behavior
The event passed to
processEventbehaves differently if assigned to a const prior to being passed in.🙂 Expected behavior
Both should be the same result. It's also worth noting that in the repro provided assignment to a
const data = ...works to resolve the problem. But in my code this doesn't end up working and instead I need to explicitly state thateventNamecan only be one of the twoEventsvalues in the ternary.Additional information about the issue
No response