Circular reference error when defining Record type

[jp7837]

TypeScript Version: 4.0.2 (and 4.1.0-dev.20201015)

Search Terms: circularly, Record

Code

type T1 = { [key: string]: T1 }
type T2 = Record<string, T2>

Expected behavior:
No compilation errors

Actual behavior:
While type T1 compiles properly, type T2 reports Type alias 'T2' circularly references itself. even though they are inherently the same type. This was actually found by autofixing a new typescript-eslint (@typescript-eslint) rule consistent-indexed-object-style

Playground Link: https://www.typescriptlang.org/play?ts=4.0.2#code/C4TwDgpgBAKgjFAvFA3lA2gawiAXFAZ2ACcBLAOwHMBdfeKAXwFgAoUSWAJiSgCUIAxgHtiAEwA8RMlQA0XAHxA

Related Issues: None found

[RyanCavanaugh]

Certain circularities are allowed (e.g. T1) but other circularities aren't, e.g.

type Identity<T> = T;
type T3 = Identity<T3>;

Generic instantiation is deferred, so at the point TS analyzes T2's declaration, it can't tell if it's in the Record case (would be allowed) or the Identity case (would not be allowed). It's only later in the process that we could tell that this is actually OK, but if it wasn't OK, it's "too late" to go back and start complaining about it.

[jp7837]

Ryan Cavanaugh (@RyanCavanaugh) thanks for the explanation. Not that it's TypeScript team's responsibility, but just as an FYI this may become a more popular issue as teams use the consistent-indexed-object-style rule from typescript-eslint (@typescript-eslint). I can file a bug on their project to not auto-fix this case if you think that's a good idea.

[gbegher]

Ryan Cavanaugh (@RyanCavanaugh) The behaviour seems a bit inconsistent to me (or at least not very transparent)

In the following example a code change somewhere deep down resulted in a failure.

Playground link

namespace Works {
 type Value = Sum<{
 PRODUCT: Product<Value>
 }>

 // Defined in another file

 type Product<T = any> = Record<string, T>;

 type ValueOf<X> = X[keyof X];
 type Sum<Cases extends Product> = ValueOf<SumMapping<Cases>>;
 type SumMapping<Cases extends Product> = {
 [cas in keyof Cases]:
 // ------ difference is here ---------
 {
 type: cas;
 value: Cases[cas];
 };
 };

 
}

namespace Fails {
 type Value = Sum<{
 PRODUCT: Product<Value>
 }>

 // Defined in another file

 type Product<T = any> = Record<string, T>;

 type ValueOf<X> = X[keyof X];
 type Sum<Cases extends Product> = ValueOf<SumMapping<Cases>>;
 type SumMapping<Cases extends Product> = {
 [cas in keyof Cases]:
 // ------ difference is here ---------
 [type: cas, value: Cases[cas]]
 };
}

[nscarcella]

Ryan Cavanaugh (@RyanCavanaugh) not sure what's under the hood of Record, but it does feel a bit inconsistent that some generics seem to work fine with recursions while others don't:

type A<T> = T | Array<A<T>> // This line works fine
type R = Record<string, R> // this one doesn't

[jedwards1211]

Ryan Cavanaugh (@RyanCavanaugh)

at the point TS analyzes T2's declaration, it can't tell if it's in the Record case (would be allowed) or the Identity case (would not be allowed)

I don't understand how what you're saying applies to OP? Because OP doesn't have an Identity type alias, only your example does.

[jedwards1211]

I guess what you're saying is that a type alias can't reference itself if it's used in a type parameter of an ordinary generic type instantiation:

type MyRecord<V> = {[key: string]: V}

type Stuff = MyRecord<string | Stuff> // circular reference error

I don't get why this is technically impossible to support though. Let's say we're checking that {a: {b: 'c'}} is of type Stuff.

My layperson imagination of how that could work is:

1. Required type gets expanded to {[key: string]: string | Stuff}
2. Check that keys of {a: {b: 'c'}} are of type string (ok)
3. check that values of {a: {b: 'c'}} are of type string | Stuff
   a. check that {b: 'c'} is of type string | Stuff
   1. It's obviously not a string, see if it's of type Stuff
   2. Required type Stuff gets expanded to {[key: string]: string | Stuff}
   3. check that keys of {b: 'c'} are of type string (ok)
   4. check that values of {b: 'c'} are of type string | Stuff
      a. check that 'c' is of type string | Stuff
      b. 'c' is of type string (ok)

Additionally, Flow supports the Stuff type just fine, so it seems perfectly possible. Or does it lead to other inconsistent behavior in Flow that I'm unaware of? Or are there some other niche cases in TS that are fundamentally incompatible with supporting the Stuff type?

[jedwards1211]

To add to what Nicolás Scarcella (@nscarcella) was saying, Array has some internal difference from an ordinary generic type alias that isn't transparent enough, because this equivalent type alias doesn't work:

type A<T> = T | Array<A<T>> // okay

type MyArray<T> = T[]

type B<T> = T | MyArray<B<T>> // errors

[jedwards1211]

Actually, I was wrong about Flow, it fails to produce expected errors on a similar recursive generic type alias:

// @flow
type Record<K, V> = {[K]: V}
type Stuff<T> = Record<string, T | Stuff<T>>
const foo: Stuff<number> = { a: 'not a number' } // should error, but doesn't

https://flow.org/try/#0PTAEAEDMBsHsHcBQAXAngBwKagEqYMawBOAJgDwDSANKAGoB8oAvKAN4DaFAugFx0C+KDNgDKyAK6RIZACqMWeQqTIBnZEQCWAOwDmNGaAA+oMZOlz6iQlrWhIsWH1NSyW8QFsARpiLy2oAEM+AHItWGRA0DcvH2DQflAQUBUAC1hxaBJQHyJiGk9xCJJYTBUtYOREIA

Maybe there is something fundamentally hard about supporting such types...I wish I had a more concrete understanding of why, because mathematically speaking, this type definition seems perfectly coherent

[RyanCavanaugh]

Imagine I told you that an integer was a flarpnumber if it was either prime or one of its digits was a flarpnumber. Is 6 a flarpnumber?

[jedwards1211]

Ryan Cavanaugh (@RyanCavanaugh) I mean obviously that seems undecidable, but I still don't see what it has to do with OP's example of type T2 = Record<string, T2>? Whether something like {foo: {}} is of type T2 seems perfectly decidable (not sure about deciding subtype/supertype relationships but that must not be a problem when T2 is defined as T2 = {[key: string]: T2}, so alias or not, the actual structure we're talking about is well-defined)