union of pattern template literals intersected with optional brand mutually assignable to one with incompatible brand

[jcalz]

🔎 Search Terms

brand, flavor, pattern template literal, placeholder, union, intersection, optional, assignable

🕗 Version & Regression Information

• This changed between versions 4.3.0-dev.20210330 and 4.3.0-dev.20210331
• This changed in commit or PR Fix template literal type relations #43440, I think

⏯ Playground Link

Playground link

💻 Code

type TmpLitUnion = `0${string}` | `1${string}`
type BrandX = TmpLitUnion & { a?: "x" };
type BrandY = TmpLitUnion & { a?: "y" };
declare const brandY: BrandY;
const brandX: BrandX = brandY; // <-- no error

🙁 Actual behavior

BrandX and BrandY are mutually assignable, even though they have an incompatible optional a property.

🙂 Expected behavior

There should be an error when trying to assign a BrandY to a BrandX or vice versa.

Additional information about the issue

This is from a Stack Overflow question. Looks like optional brands (this is called... "flavored" I guess?) don't distinguish between unions-of-pattern-template-literals. If you get rid of the union, you get the expected error:

type TmpLit = `0${string}`;
type BrandX = TmpLit & { a?: "x" };
type BrandY = TmpLit & { a?: "y" };
declare const brandY: BrandY;
const brandX: BrandX = brandY; // <-- error

Or if you add something else to the union, you get the expected error:

type TmpLitUnionOrSomethingElse = `0${string}` | `1${string}` | "somethingElse"
type BrandX = TmpLitUnionOrSomethingElse & { a?: "x" };
type BrandY = TmpLitUnionOrSomethingElse & { a?: "y" };
declare const brandY: BrandY;
const brandX: BrandX = brandY; // <-- error

Or if the brand is not optional, etc.

Not sure if this is a bug or a design limitation, or somehow intentional.

[RyanCavanaugh]

🤖 Thank you for your issue! I've done some analysis to help get you started. This response is automatically generated; feel free to 👍 or 👎 this comment according to its usefulness.

Possible Relevant FAQs

Nominal or Tagged Types

This assignment is allowed because the two “brand” interfaces are still structurally identical from the type-checker’s perspective.

1. Both BrandX and BrandY are intersections of the same union (TmpLitUnion) with an object type that contains a single optional property a.
2. An optional property can be omitted. The empty object {} therefore satisfies both { a?: "x" } and { a?: "y" } since leaving out a is always valid.
3. Because every value of BrandY could be an object with no a property at all—and such an object is also valid for BrandX—the two types are deemed mutually assignable. The differing literal types on a don’t create an incompatibility once the property is optional.

Branded (a.k.a. nominal or tagged) tricks only work when the branding property is required and has a unique, incompatible type. For example:

type TmpLitUnion = `0${string}` | `1${string}`;

type BrandX = TmpLitUnion & { a: "x" };
type BrandY = TmpLitUnion & { a: "y" };

declare const y: BrandY;
const x: BrandX = y; // error – types are now incompatible

If nominal separation at the type level is needed without relying on these structural hacks, track the long-standing proposal in issue #202, which covers first-class support for nominal or tagged types.

Similar Issues

Here are the most similar issues I found

• (69%) microsoft/typescript#61098: Type containing templated, branded string is not assignable to itself
• (68%) microsoft/typescript#41718: String literal intersection type unioned with String properties evaluates to non-literal string
• (66%) microsoft/typescript#25958: Bug with union types
• (66%) microsoft/typescript#61174: Assignable TemplateLiteral of Intersection Type of Primitive and {} to Primitive String
• (66%) microsoft/typescript#61093: Branded literal type widened in unexpected way
• (66%) microsoft/typescript#14855: Intersections allow assignment of incompatible types
• (65%) microsoft/typescript#26758: Generic type is not expanded when typechecking equality check
• (65%) microsoft/typescript#43852: Nominal/branded key for `Record` disables checking/inferring of value type
• (65%) microsoft/typescript#56635: union type no type was matched and no error was reported.
• (65%) microsoft/typescript#10892: string & Type intersection produce error in switch statement

If your issue is a duplicate of one of these, feel free to close this issue. Otherwise, no action is needed.

Possibly Working as Intended

It looks like this behavior might be intentional. Here's what a computer had to say about it.

BrandX and BrandY differ in the type of the optional property a, so they are not supposed to be mutually assignable. When the same branding trick is used with a single template-literal type (or with a mandatory property) the compiler correctly reports an error, so the fact that the error disappears only when the template-literal type is a union strongly suggests an incompleteness in the assignability algorithm that was introduced in the referenced 4.3 change. This is therefore not intentional behavior; it’s an accept-error bug.