Unexpected error message when assigning object values with wider discriminator property type

[janpaepke]

🔎 Search Terms

discriminated unions, property incompatibility

🕗 Version & Regression Information

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

⏯ Playground Link

https://www.typescriptlang.org/play/?ts=3.9.7#code/C4TwDgpgBAqgdgSwPZwCrmgXigIgGZJI5QA+uARgIYBOxZOVAXjgNwBQbokUAIggM4BjaggC2COJWAQAJlExsopKAG9FSjTIHCxEqUmoAuXASLsNUAL7qyai0q1CR4ycAPGGNVuqWX2HQRR+YCgIAA9IQWkZAFFqandebWc9aPlVKEcdF30jE0JiSn5YRBR0bms2QLhgqABXOHDI6LiEvL4nXVdZdJVM5K7cj1NiSygijKyU10T4ZDQMK3YgA

💻 Code

type UnionType = "foo" | "bar" | "baz";

type Discriminated =
  | {
      discriminator: "foo";
    }
  | {
      discriminator: "bar";
    };


const expectedError: Discriminated = { discriminator: "foo" as UnionType }

const unexpectedError: Discriminated = { discriminator: "foo" } as { discriminator: UnionType };

🙁 Actual behavior

For unexpectedError, this is the compiler message:

Type '{ discriminator: UnionType; }' is not assignable to type 'Discriminated'.
  Type '{ discriminator: UnionType; }' is not assignable to type '{ discriminator: "bar"; }'.
    Types of property 'discriminator' are incompatible.
      Type 'UnionType' is not assignable to type '"bar"'.
        Type '"foo"' is not assignable to type '"bar"'.

This error is very misleading since "foo" is not actually the problem here, it's "baz".
In fact the error goes away, if we remove "baz" from the union.

🙂 Expected behavior

For expectedError the compiler states:

Type 'UnionType' is not assignable to type '"foo" | "bar"'.
  Type '"baz"' is not assignable to type '"foo" | "bar"'.

Consequently, the correct error message I would expect for unexpectedError is this:

Type '{ discriminator: UnionType; }' is not assignable to type 'Discriminated'.
  Type '{ discriminator: UnionType; }' is not assignable to type '{ discriminator: "foo" | "bar"; }'.
    Types of property 'discriminator' are incompatible.
      Type 'UnionType' is not assignable to type '"foo" | "bar"'.
        Type '"baz"' is not assignable to type '"foo" | "bar"'.

Additional information about the issue

This is a simplified example of this issue, which I discovered, when attempting to supply a parameter a function expecting a discriminated union.
The supplied variable had a wider range of possible discriminator values, like shown in this example.

[RyanCavanaugh]

Both error messages are correct, because at the end of the day { x: A | B } is not something that can in general be combinatorially exploded to { x: A } | { x: B }. Object literals get a little special sauce because we can make better determinations about them.

The more-confusing error is arguably more correct because it more directly follows from what's happening. It's legitimately describing the implied case where you'd be trying to assign { x: A | B } to { x: B } and noting that A is not in the target. That's actually what's wrong here.

[janpaepke]

Hi Ryan, thanks for taking the time to review this.

After trying to wrap my head around your answer, I believe you're technically correct (the best kind of correct).

I would still argue that this is highly confusing and counter-intuitive from a DX perspective. The error "Type 'foo' is not assignable to type 'bar'" misleadingly suggests that the literal "foo" itself is incompatible, when the actual problem is that the source type includes "baz" in its union, which has no corresponding variant in the target discriminated union.

I understand that TypeScript's current error reflects the internal comparison algorithm ({ x: A | B } -> { x: B } fails because component A doesn't match). However, from a developer's perspective, the root cause is the presence of "baz" in the source union – something the current error message doesn't communicate at all.

With more complex data types and larger unions, this can send the developer in the completely wrong direction, as it did in our case.

It comes down to whether compiler errors should reflect:

1. The technical issue within the type-checking algorithm, or
2. Actionable information that guides developers to the source of the incompatibility

I recognize there's a tradeoff here, but I'd argue this is at least worth exploring.

[RyanCavanaugh]

I don't really disagree in principle, but we have several hundred concretely more pressing issues to address first. Someone else can look into this if they want to.

[typescript-bot]

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

[janpaepke]

Is closing this the correct, if we agree this would be a "nice to have", admittedly with low priority?

[RyanCavanaugh]

Feel free to open a new issue using the Suggestion template