How to print anonymous recursive types

[JsonFreeman]

var a: { foo: typeof a; }

a has a recursive type. If we try to print this type, it prints { foo: any; }, but it does not behave as such in type comparisons. So we are lying when we print it.

When fixing this, it's important to consider both displaying a type to the user, and generating .d.ts files.

[danquirk]

Related to #402?

[JsonFreeman]

Yes, it is related

[ahejlsberg]

I don't think that should be a bug. Consider:

declare function f(): { foo: typeof f; }
var g: () => { foo: typeof g; }

We currently permit both of those and correctly generate recursive types. The old compiler is oddly inconsistent in these cases, making an any in f but not in g. The new compiler handles both, as well as your initial example.

We should fix the type printer to handle the recursion.

[JsonFreeman]

I think recursive types are nice, but typeToString does not print them correctly. Right now if you try to print the type of a in my initial example:

var a: { foo: typeof a; };

You get { foo: any; }, which is not the correct type. That means if you have the following test:

var a: { foo: typeof a; };
var a: { foo: any; };

You will get an error that the types are not identical, yet the resulting error will tell you that both types are { foo: any; }. We could say that recursive types are allowed and this is just a bug in typeToString. But then we'd also have to make sure that it works in .d.ts generation.

[JsonFreeman]

Also, if we keep the type recursive and do not change it to { foo: any; }, then we have to do that for all the following cases too:

var a = { foo: a };
var b = [b];
var c = () => c;

[JsonFreeman]

And then we'd get into inconsistencies when we have something of the following form:

var a = foo(a);

for some function foo.
The reason we do not have this problem for function declarations, module instance types, and class constructor types is that we already know something about the structure of these types, just by virtue of the semantics of declaring these entities. For example, an instantiated module will always be an object type whose properties are its exports, and therefore we have a structural basis for making a recursive type that behaves consistently.
For vars, we do not have this luxury because a var can have any type at all. We have no basis for defining the structure of a type, and then making it recursive because we have to resolve the expression on the right hand side before we know anything.
Unless you are saying that we should support recursive types only in the type annotation of a var, and not its initializer! This is plausible, but then we would have to have a special check for the non-contractive case:

var a: typeof a;

[ahejlsberg]

Yes, I was talking recursive types in type annotations. This is something we already support and we shouldn't undo that simply because we can't produce an accurate string representation of those types. I think the current solution of outputting any when recursion is detected in an unnamed type is a reasonable compromise.

We might consider outputting ... instead, perhaps after a couple of iterations:

{ foo: { foo: { foo: ... } } }

But that obviously is more work and might cause us to generate an invalid .d.ts unless we also include logic to produce errors in such cases.

[JsonFreeman]

I don't think we should deemphasize the importance of printing the type correctly. It is a big part of the user experience of the language. I do think that we should ensure we have a reasonable way to print a type before trying to support it in the type system. One thing the user should never get is a message like the following:

Subsequent variable declarations must have the same type. Variable 'a' must be of type '{ foo: any; }', but here has type '{ foo: any; }'.

This is the result of trying to compile the example I provided above:

var a: { foo: typeof a; };
var a: { foo: any; };

[JsonFreeman]

I'm going to reopen this bug and change the title. This bug is still tracking the issue for actually printing the types correctly. There is good material here we can use for that. Also going to mention design bug #517, since it's very relevant here.

[mhegazy]

A fix here should handle the case outlined in #475.

[Andarist]

To the best of my understanding of the issue at hand - this is already fixed and the issue could be closed cc @RyanCavanaugh

[RyanCavanaugh]

Wow, throwback. Indeed. Thanks @Andarist !