Design Meeting Notes, 7/14/2021

[DanielRosenwasser]

Increasing the Type Instantiation Depth Limit

#45025

• People keep doing more and more advanced patterns in type-space; the instantiation depth limiter is too low for these scenarios.

• For creating a union of characters as in the PR,

  type GetChars<S> = S extends `${infer Char}${infer Rest }` ? Char | GetChars<Rest> : never;

  you have 2 instantiations: the outer conditional type and the union in the true branch.

  • Means you can only get 24 characters deep before TypeScript gives you a 😢.

• Other alternatives:

  • generators - slow, ugly output
  • explicit stack management - not a totally natural fit

• Risks:

  • More memory usage
  • Slower non-termination of infinitely expanding types.
    • Can impact the language service.

• Conservative estimate of about 100 bytes per stack frame.

  • Ball-parked from playing around with examples, but is variable.

• Have we played with non-V8 engines?

  • Not much.
  • Does Safari do any better? It implements Tail Call Optimization
    • But our instantiation logic is not tail-recursive (even when instantiating a tail-recursive type).
  • There are certian places where functions hand off directly to another function though - in certain cases, yes, that would help - but only as far as inlining would help.

• Concerns around LS still hold - but instantiationCount limit on source elements helps a bit.

  https://github.com/microsoft/TypeScript/blob/541e553163bb79fba64fdfd7c8a2c96f201c3b0a/src/compiler/checker.ts#16255

  • Still a much bigger limit than the instantiation depth limit as well.

• Making the instantiation depth configurable?

  • Nope, not comfortable with that.

• Shipping this in 4.5?

  • Would rather not make people wait for the change.
  • A small increase in depth limits in 4.3 would have saved people

• Can we message this as a "be cautious about relying strongly on this behavior" in the release notes?

  • Seems hard to message that.

• Could try type-call elimination to avoid blowing our own stack.

Auto-Imports and the node: Prefix

#43842

• Concerns about module augmentations - need to come back to this when others on the team can bring up concerns.
• Will be developing a "more correct" thing in the meantime.

Contextually Typing IIFEs

#44992
#45007

• Not especially useful - unless you have an async function!
• We already contextually type IIFE parameters.
  • Does that have any strange interactions?
    • Unclear right now - probably not.
• Seems reasonable, but need to think about this a bit.

Import Assertions

#40698

• History
  • Subresource integrity enforcement - had cascading effects.
  • JSON modules culminated in this proposal.
  • Right side of this looks like an expression, but isn't an expression.
• Maybe the better direction would've been to just have a "don't execute this" assertion instead.

[treybrisbane]

But our instantiation logic is not tail-recursive (even when instantiating a tail-recursive type).

Perhaps implementing tail-call optimisation for types is worth investigating? It won't cover all problem cases, but perhaps it'll be good enough for most recursive transforms people are using?

FWIW I generally try to write my recursive types in a tail-recursive manner anyway, so it would definitely help me! 😄