Relax the recursive type restriction.

[aatxe]

Rendered.

[hgoldstein]

Maybe more of a nit: don't we already have equirecursive types? I would think that any class-ish looking table would be one.

[hgoldstein]

Talked offline: you could consider type inference as constructing equirecursive types, but this PR is about relaxing the current restrictions on recursive types, and saying we will implement such via isorecursion.

[aatxe]

In some sense, type inference will sometimes construct a recursive type that you could probably consider equirecursive, e.g. t1 where t1 = { foo(self: t1) -> ... } but this is one of the things that hampers the developer experience by leading to complex types, and is not supported by any of our syntax for actually annotating types. It's strictly a representation of a cyclic type that has occurred because of inference. #5 should also hopefully help us get rid of those patterns as well.

[vegorov-rbx]

Relation to #2 could be noted.

[aatxe]

Relation to #2 could be noted.

Honestly, did not remember that it existed, but the relation between the two is that the old one was proposing a caching strategy to allow finite expansions that would work as a mild relaxation of the already in-place restriction. This is proposing what was listed as the top alternative (infinite expansion). I don't know whether we will or won't implement a cache for that expansion (which was the top two alternatives), but frankly, I think that caching or not for this strategy is an implementation detail and not a part of the language design proposal. We probably do not want to implement caching in the type system that has an impact on the static semantics.

I'll bring over the alternatives from #2 though.

[vegorov-rbx]

I view it as an implementation detail for the old solver similar to how your proposal mentions by treating type aliases as proper type functions that are lazily expanded when their contents are needed in the new solver.

I don't think it's that bad to explain it, but it could have been in the PR desc as opposed to the RFC body (edit: in the previous RFC).
Didn't feel to me that described caching there was particularly arbitrary.

I'm also not saying that it has to be made that way, but it is prior art for the same problem and I would say that RFC was already accepted in spirit, but we switched gears on the implementation.
If new solver has a simpler implementation without exploding, I'm all for this RFC as well.