Closed
Description
Recursive Conditional Types
- @tycho01 already reiterated we have recursive conditional types with indexed access types on object types (Add Awaited<T> to core library #21613 (comment))
- Well damn it, if you can already do it with object types, why make it ugly to do with regular conditional types?
- Conditional types contain 4 types
- The checked type, the extends type, the true type, and the false type
- When the condition is definitely true or false, we do an immediate instantiation (/evaluation) of the respective branch
- Those branches are already sort of deferral points, much like the object member types.
- If an conditional type is instantiated over 100 times, we consider that to be too deep.
- At that point, we try to find the respective alias type that contains that conditional type.
- [[Demonstration of Peano-style arithmetic with multiplication]]
- Challenges
- The "we've instantiated too deeply" error is issued on the declaration instead of the usage, which is not totally obvious.
- The act of checking whether a type satisfies a constraint in a conditional type (e.g. seeing if
A
is assignable toB
inA extends B
) requires evaluatingA
.- That means if
A
is a conditional type, either branch needs to be evaluated immediately to see if it satisfiesB
. That means you can end up exhausting your instantiation stack.
- That means if
- Question: Why not defer the type when comparing a conditional to the constraint type.
- doesn't make sense, you need to check now
- you could imagine that our compiler architecture was more deferred, but that would make it much harder to reason about.
- doesn't make sense, you need to check now
- Question: or, when you hit the limit, stop evaluating once you hit the limit and defer the evaluation?
- Also, this instantiation stack limit is quite annoying: you can get errors on unrelated type aliases.
- What if your stack is tied per type instantiation?
- Or rather than per type, you use the global stack but check specific types in that stack.
- Conclusion: give users an error in these situations, try to improve the message.
Ignore specific errors with @ts-ignore
comments
- Given the error code, what are you actually suppressing?
- Seems entirely unclear.
- Error codes don't tell you what you're doing
- Short-names are better than numbers.
- So short names?
- But this gives a bad UX; way more on the screen than you wanted.
- Also, people are probably relying on the error codes even though they shouldn't be!!
- What if we gave short codes in
--pretty
?
- Could give quick info for the error code.
- Great but how does that help you on a code review on GitHub?
- Why, do you inherently distrust the code you're reviewing?
- Sometimes yes?
- Why, do you inherently distrust the code you're reviewing?
- Great but how does that help you on a code review on GitHub?
- A lot of these are to suppress lint rules.
- Maybe the solution is just to get out of the linting business. :)
- What if these comments caused errors when no error's present on the next line?
- We might feel better about that.
- Half jokingly: Can you suppress those errors?
- Now the idea has become a half-joke.
- Half jokingly: Can you suppress those errors?
- We might feel better about that.
- Conclusion: no conclusion yet.
- Post-design meeting realization: original motivation was mass suppression for working code.
- Seems more reasonable with that in mind.