Repository navigation
Design Meeting Notes, 7/14/2021 #45104
Copy link
Copy link
Closed
Labels
Design NotesNotes from our design meetingsNotes from our design meetings
Description
Increasing the Type Instantiation Depth Limit
-
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
instantiationCountlimit on source elements helps a bit.- 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
- 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
- Not especially useful - unless you have an
asyncfunction! - We already contextually type IIFE parameters.
- Does that have any strange interactions?
- Unclear right now - probably not.
- Does that have any strange interactions?
- Seems reasonable, but need to think about this a bit.
Import Assertions
- 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.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Design NotesNotes from our design meetingsNotes from our design meetings
Activity
treybrisbane commentedon Jul 20, 2021
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! 😄
[-]Design Meeting Notes, 7/2/2021[/-][+]Design Meeting Notes, 7/14/2021[/+]