Recursive type literals

[sophiajt]

Introduction

Currently, type literals are capable of representing any instantiated (non-generic) type except those that are recursive. This is because, as an anonymous type, they do not have a name with which to create this type.

This proposal covers recursive type literals. These type literals add the additional ability of the literal referring to itself. This has one main advantage: emitting .d.ts files for expressions typed by class expressions now have a "flattened" representations. As class expressions could easily have recursive components, we'd like to be able to emit a corresponding type representation into the .d.ts file without contaminating the namespace with additional fresh type names.

Design

var x : <Node> { next: Node; value: number; };

The above acts similarly to this example:

interface Node { next: Node; value: number; };
var x : Node; 

with one critical exception: in the first example the 'Node' name is not visible outside of the type literal.

Typechecking

Typechecking of recursive type literals works just as recursive interfaces, with the exception (as mentioned above) that the name given to the recursive type literal is not visible in the lexical scope outside of the type literal. Otherwise, these expand and are compared for equality structurally just as interfaces.

Differences with other designs

This design differs from similar designs, named the 'self' type design where there is a specific keywords that the type can refer to its self. This proposal is strictly more expressive, albeit at the cost of some additional syntax. For example, embedded recursive types are possible:

var x: <Node> { up: <Parent>{ up: Parent; node: Node}; next: Node; value: number};

[ahejlsberg]

It's already easy to write a recursive type by declaring an interface and referencing it within itself, so as a practical matter self-referential type literals are only interesting in places where you can't declare interfaces. Such places include function bodies, but we've already discussed fixing that. I think if we did there wouldn't be many places in user written code where self-referential type literals would be useful. Furthermore, I think it would be confusing to have two ways of naming types.

That said, I realize we have an issue with self-referential types in auto-generated code (such as .d.ts files). I think we should consider introducing a simple way of referencing an enclosing type without giving it a name. For example, we could have ^ refer to the immediately enclosing type, ^^ to the next enclosing type, and so on. You could then write your example:

var x: { up: { up: ^; node: ^^; }; next: ^; value: number};

A couple of other examples:

var stringList: { data: string; next: ^; };
var selfFunc: () => ^;

I prefer this for two reasons: One, no names are introduced and thus there is no name scope confusion. Two, in auto-generated code we'd have to synthesize names such as _T1, _T2, etc. which really wouldn't be pretty. With the ^ syntax we wouldn't have to.

[DanielRosenwasser]

That's a very good point - it seems like part of our philosophy in emit when it comes to TypeScript has been to avoid generating names (i.e. it has always been easy to support variables named _this in any context but we do not).

However, while I understand the value of predictable/deterministic output, I think something like ^ is non-obvious, a little hard on the eyes, and has low "searchability" (i.e. what search query do you use to figure out what's going on here? "^ in TypeScript types"? "Carat in TypeScript types"?).

The biggest win is that naming each recursive portion brings a lot of clarity.

Hey, why not take advantage of that unicode support for auto-generating names? What about τ1, τ2, etc.? 😉

[RyanCavanaugh]

I think we should consider introducing a simple way of referencing an enclosing type without giving it a name. [... ] With the ^ syntax we wouldn't have to.

In class expressions, the containing type is often going to be the constructor function instead of the instance type. Without a way to name the instance type within the constructor function type literal, we're going to end up writing out the instance type over and over and over again in the .d.ts file. ^ is still useful but we need something else to make anonymous class types generate nicely.

[sophiajt]

@RyanCavanaugh - right, I didn't mention that here, but that's a good example. It also calls back to what @ahejlsberg alludes to in his first paragraph.

For example:

// example.ts
var c = class Node { 
  constructor(public data: any) { }  
  next: Node;
  prev: Node;
  static default: Node;
}

Would become this .d.ts:

// example.d.ts
var c: {new(data: any): {next: ^; prev: ^; data: any}; default: {next: ^; prev: ^; data: any};};

Every usage of the class type ends up duplicating the type, which gets unreadable pretty quickly. Something @RyanCavanaugh and I noticed while sketching it out on the whiteboard is that you want to be able to embed interfaces in these types:

// example(revised).d.ts
var c: {new(data: any): Instance; default: Instance;
  interface Instance {next: Instance; prev: Instance; data: any};
};

Taking it one step further, perhaps allowing interfaces in more places is a better general fix. I could see another possible way of writing my original example as:

var x: interface Node { up: interface Parent { up: Parent; node: Node}; next: Node; value: number};

I'm not wed to any particular syntax.

[JsonFreeman]

I don't see any reason to allow ^ to refer to the class level. I think if we do it, ^ should only be allowed in anonymous types because classes already provide a mechanism for naming their instance and constructor sides (e.g. C, typeof C).

[mhegazy]

+1 for the use of interface keyword as a type reference. I think it is consistent with class and function expression before it.

[JsonFreeman]

Yeah I like that too. It seems like part of the family.

[ahejlsberg]

I see the (subtle) similarity with named function expressions and the scope of their identifiers, but I really don't see much of a need for this feature. In particular, I think it is an overly complex solution to the problem of referencing the enclosing type and it would still require type-to-string conversions to invent a name for the type, e.g.

var a: interface _T { (): _T; };

I would much prefer the simple ^ and then use regular interface declarations for more complicated scenarios.

[JsonFreeman]

I think the interface keyword solution is not complex from the user's perspective, it is very smooth. It would require us to do some work in the language, but it is very intuitive. Ryan's concern about what ^ means in a class still stands. Additionally, I worry about the readability of this because the user has to count the levels of the type! I think you should not have to count to read a type.

[JsonFreeman]

We also would have to come up with rules for where a ^ is licensed, and what it means in each licensing context.

[ahejlsberg]

As I understand it, the only real world problem we're trying to solve here is a way of denoting recursive type literals in auto-generated code. I have yet to be convinced there is a real world need for locally named interfaces in type literals in user written code because regular named types are entirely adequate (modulo our lack of local type declarations in functions which I'm definitely in favor of fixing). I think the ^ is a nice scoped solution to the actual problem. It's usage will be rare and defining the contexts and meanings shouldn't be hard.