A union of identical types fails identicality

[rickosborne]

tl;dr

When identicality checking the received type R and expected type E, the check will fail if one (say, R) is a union, say R = R1 | R2, even if E is identical to all parts of the union, E === R1 and E === R2, and the parts of the union are also identical, R1 === R2.

That is, it seems like an additional check in identicality.ts could recurse into intersection types and return true if all parts of each union are identical.

Setup

This is the type I was working on:

/**
 * Remove the "wildcard" parts of an object, leaving only the concrete,
 * specified parts.  That is, it removes any keys which could be any
 * string, any number, or any symbol.
 */
export type NoRecord<T extends object> = object extends T ? Record<never, unknown> : {
	[K in keyof T as K extends string ? string extends K ? never : K : K extends symbol ? symbol extends K ? never : K : K extends number ? number extends K ? never : K : never]: T[K];
};

I then have some test fixture types which include the record behavior I want to filter out:

type AnyRecord = {
	readonly id: number;
	flag?: boolean;
} & Record<string | number | symbol, string>;

type StringRecord = {
	readonly id: number;
	flag?: boolean;
} & Record<string, string>;

type NumberRecord = {
	readonly id: number;
	flag?: boolean;
	[key: number]: string;
}

type SymbolRecord = {
	readonly id: number;
	flag?: boolean;
	[key: symbol]: string;
}

When run through NoRecord, all of these should reduce to:

type Specifics = {
	readonly id: number;
	flag?: boolean;
};

I also have a helper function which does nothing but hold type signatures:

const f = <T>(): T => undefined as T;

The parts which work fine:

expectType<Specifics>(f<NoRecord<AnyRecord>>());  // ✅
expectType<Specifics>(f<NoRecord<StringRecord>>());  // ✅
expectType<Specifics>(f<NoRecord<NumberRecord>>());  // ✅
expectType<Specifics>(f<NoRecord<SymbolRecord>>());  // ✅

But this breaks:

expectType<Specifics>(f<NoRecord<NumberRecord | StringRecord>>());  // ❌

If you relax the test to assignability, it will pass just fine:

expectAssignable<Specifics>(f<NoRecord<SymbolRecord | StringRecord>>());  // ✅
expectAssignable<NoRecord<SymbolRecord | StringRecord>>(f<Specifics>());  // ✅
expectAssignable<Specifics>(f<NoRecord<SymbolRecord | NumberRecord>>());  // ✅
expectAssignable<Specifics>(f<NoRecord<NumberRecord | StringRecord>>());  // ✅

For the failure of the strict check, the error you get is:

  ✖  47:0  Parameter type Specifics is not identical to argument type { readonly id: number; flag?: boolean | undefined; } | { readonly id: number; flag?: boolean | undefined; }.

- { readonly id: number; flag?: boolean | undefined; }
+ { readonly id: number; flag?: boolean | undefined; } | { readonly id: number; flag?: boolean | undefined; }  

This is, at first, mystifying. "Hey. Why is that still a union if the two types are the same? Why doesn't it collapse?" I assume there's a perfectly good reason for this at the tsc level ... but I am not smart enough to understand it.

Fire up a debugger on the failing assertion, and you end up in identical.ts:53. It sees the received type as a union of two subtypes. And if I exhaustively compare them:

checker.isTypeIdenticalTo(expectedType, receivedType.types[0])  // E === R1? true
checker.isTypeIdenticalTo(expectedType, receivedType.types[1])  // E === R2? true
checker.isTypeIdenticalTo(receivedType.types[0], receivedType.types[1])  // R1 === R2? true

All the subtypes are considered identical, but the two top-level types are not.

[rickosborne]

Oh, and I guess I should say, you don't see the error until you actually run the tests. That is, there are no squigglies at coding time.

And for completeness, I also ran it through expect-type, which also passes it without any squigglies.

expectTypeOf(f<NoRecord<NumberRecord | StringRecord>>()).toEqualTypeOf<Specifics>();  // ✅
expectTypeOf<Specifics>().toEqualTypeOf(f<NoRecord<NumberRecord | StringRecord>>());  // ✅

[rickosborne]

And after typing all this up it occurs to me that I could reduce the complexity of that type. But it doesn't change the outcome above.

export type NoRecord<T extends object> = object extends T ? Record<never, unknown> : {
	[K in keyof T as string extends K ? never : symbol extends K ? never : number extends K ? never : K]: T[K];
};

[rickosborne]

For posterity, I decided to go back to my basic assumptions about how tsc works with records. Turns out, everything I thought I knew was false.

None of this changes the original issue. I still think an exhaustive union identicality checker would be nice (even if it got its own expectTransitiveIdenticality or something).

Anyway ... for some added color ...

I simplified the record types to make them as uniform as possible, except the key type:

type AnyRecord = {
	readonly id: string;
	[key: string | number | symbol]: string;
};

type StringRecord = {
	readonly id: string;
	[key: string]: string;
};

type NumberRecord = {
	readonly id: string;
	[key: number]: string;
}

type SymbolRecord = {
	readonly id: string;
	[key: symbol]: string;
}

type Specifics = {
	readonly id: string;
};

All the tests I showed in my original post still produce the same results, both successes and failures.

I created some variables which would align with those types, but were not explicitly typed, so I could check my assumptions about assignability.

// Note the lack of explicit typing here.
// We're not telling tsc to throw anything away.
let numberRecord = { id: "id", 2: "2" };  // inferred as { id: string; [x: number]: string }
let symbolRecord = { id: "id", [Symbol("symbol")]: "symbol" };  // inferred as { id: string; [x: symbol]: string }
let stringRecord = { id: "id", str: "string" };  // inferred as { id: string; [x: string]: string }

Are they each assignable to those types? Yes.

expectAssignable<NumberRecord>(numberRecord);  // ✅
expectAssignable<SymbolRecord>(symbolRecord);  // ✅
expectAssignable<StringRecord>(stringRecord);  // ✅

I would not expect the reverse to be true. And yet ...

expectNotAssignable<typeof numberRecord>(f<NumberRecord>()); // ✅
expectNotAssignable<typeof stringRecord>(f<StringRecord>()); // ✅
expectNotAssignable<typeof symbolRecord>(f<SymbolRecord>()); // ❌

That last one yields:

  ✖  59:0  Argument of type SymbolRecord is assignable to parameter of type { [x: symbol]: string; id: string; }.

- { [x: symbol]: string; id: string; }
+ { [key: symbol]: string; readonly id: string; }  

I'm not sure why tsc thinks this should be okay. I can't come up with a rationale here. I could kindof-maybe see assignability NumberRecord and StringRecord as reasonable knowing that numeric keys will get coerced into string keys ... but symbols? No clue.

But ... trudging on ... I thought I'd check to see if the types themselves were assignable. My assumption was that they should not be, as they have different key types. But I was wrong.

// Cross-assigning shouldn't work ... should it?
expectNotAssignable<NumberRecord>(f<SymbolRecord>());  // ❌
expectNotAssignable<NumberRecord>(f<StringRecord>());  // ❌
expectNotAssignable<StringRecord>(f<NumberRecord>());  // ❌
expectNotAssignable<StringRecord>(f<SymbolRecord>());  // ❌
expectNotAssignable<SymbolRecord>(f<StringRecord>());  // ❌
expectNotAssignable<SymbolRecord>(f<NumberRecord>());  // ❌

You get similar errors as the above:

  ✖  79:0  Argument of type { [x: symbol]: string; id: string; } is assignable to parameter of type NumberRecord.

- { [key: number]: string; readonly id: string; }
+ { [x: symbol]: string; id: string; }  

To be sure this wasn't a tsd problem, I wrote the equivalent out in code to see if tsc complained about the assignments:

// Now we'll have tsc throw away the specifics and just use the types.
let sym: symbol = Symbol("sym");
let numberTyped: NumberRecord = numberRecord;
let stringTyped: StringRecord = stringRecord;
let symbolTyped: SymbolRecord = symbolRecord;
let anyTyped: AnyRecord = { id: "any", 2: "2", s: "s", [sym]: "sym" };

// tsc complains about none of this.  Which is ... 🤯😱
if (numberTyped[1] === stringTyped.foo) numberTyped = stringTyped;    // ✅🤯
if (numberTyped[2] === symbolTyped[sym]) numberTyped = symbolTyped;   // ✅🤯
if (numberTyped[2] === anyTyped.foo) numberTyped = anyTyped;          // ✅🤯
if (stringTyped.bar === numberTyped[3]) stringTyped = numberTyped;    // ✅🤯
if (stringTyped.baz === symbolTyped.id) stringTyped = symbolTyped;    // ✅🤯
if (stringTyped.foo === anyTyped[9]) stringTyped = anyTyped;          // ✅🤯
if (symbolTyped[sym] === numberTyped[4]) symbolTyped = numberTyped;   // ✅🤯
if (symbolTyped[sym] === stringTyped.quux) symbolTyped = stringTyped; // ✅🤯
if (symbolTyped[sym] === anyTyped[8]) symbolTyped = anyTyped;         // ✅🤯

So ... as near as I can tell, the key type of a Record basically does does not affect its assignability to any other type of record.

Unreal.

And, to be sure, my tsconfig.json includes:

{
	"compilerOptions": {
		"noImplicitAny": true,
		"noImplicitOverride": true,
		"noImplicitReturns": true,
		"noImplicitThis": true,
		"strict": true,
		"strictBindCallApply": true,
		"strictFunctionTypes": true,
		"strictNullChecks": true,
		"strictPropertyInitialization": true,
	}
}

BRB. Rethinking my life choices.

[rickosborne]

Okay, sorry for the spam. Last one today. Seems like the 🤯😱 above is related to microsoft/TypeScript#29698 . So, again, not tsd's fault, and not directly related to the original issue. Just additional color for the setup of the original issue.