Type alias recursion is resolved eagerly when the alias is generic and its arguments are derived from inferred members of conditional types

[dead-claudia]

TypeScript Version: 3.9.0-beta

Search Terms: recursive, recursive generic

Code

type Intersect<U extends any[], R = unknown> =
    ((...u: U) => any) extends ((h: infer H, ...t: infer T) => any)
        ? Intersect<T, R & H>
        : R

const value: Intersect<[{a: number}, {b: number}]> = {
    a: 1,
    b: 2
}

Note: the usual workaround of an immediately-indexed intermediate object type still works.

Expected behavior: It to type check without warnings

Actual behavior:

• At line 1: Type alias 'Intersect' circularly references itself. (2456)
• At line 3: Type 'Intersect' is not generic. (2315)
• At line 6: Type 'Intersect' is not generic. (2315)

Playground Link: Link

Related Issues:

• Circularities Only Blocked Sometimes #37426 (root cause might be this)
• Recursive type alias in union type breaks in 3.8.3 #37344
• Probably about 25%-30% of all other recursive type issues.
• My use case is basically solving Tuple iteration and merging #26058 in userland, and doing this with SomeTuple[number] won't work because I don't want to recurse.

[weswigham]

So, I spent awhile looking into this - first off, this is working as intended right now, and this is in no way a regression as the same behaviors exist far into the past (so almost certainly shouldn't be scheduled for 3.9.1, I'll move it). Our final design for recursive type aliases only allows recursion on class, interface, and tuple types. This means that aliases to anonymous objects, aliases to unions, aliases to conditionals - none of those can be recursive in the final design (I had a prototype with a more expanded implementation, but this is what we ultimately went with).

Now, enable recursive aliasing for these other cases certainly is possible, but it is not free to do so; we can't actually re-purpose the machinery enabling recursive type aliases for class/interface/tuple types for other kinds of aliases at all. It relies on generic object instantiation as a natural point of deferral in the existing instantiation pipeline. We'd need to use the deferred alias/deferred substitution machinery I had in place in my prototype instead. In addition to that, deferral only works when the type constructors which consume those deferred types keep them deferred - patching holes in that logic is what many of our recursive type alias bugfixes for the current implementation have been thus far, and adding essentially a second implementation will mean more work there. Certainly not impossible and, as I said, most of the work has already been prototyped once, but we'd have to revisit our implementation and decide that the usecases the capabilities enable are worth the increased complexity. I could repost the PR with the broader implementation, but there's not much of a point unless we commit to wanting to enable these usecases first~