Closed
Description
Generalized Index Signatures
- People ask for an index signature for
symbol
. - But also now that we have template literal types, people want stuff like
`data-${string}`
.- But if you allow things like that, you have to allow generics.
- You can get the same effect today with mapped types.
- Today we do relation checking for
string
andnumber
index signatures in a pretty loose way.- Seems like we need some loose rules.
- Do we? Seems like you can create a slight loosening.
- You need to be sensitive to the signatures with which an overload overlaps.
- With
noUncheckedIndexedAccess
, we have another layer of relating differently. - Would it be possible to have generic index signatures?
- Maybe, but we don't exactly know how that would work.
- The original idea was to unify mapped types and index signatures.
importsNotUsedAsValues: preserve
Doesn't Preserve Names
Perf Regressions
- Caused by better aliasing of union types.
- 1.5s to 5s regression
- The actual repro was 30s to 50s.
- But this is expected - like a see-saw, we did better on other codebases, but we'll do worse on this one.
- It's expected because we're manufacturing new type IDs.
- But we can potentially do some cleverness with the non-aliased union type.
- Experiment.
- Swapping a declaration/statement actually slows down the type-checking process.
- We cache a whole bunch of type relationships before hitting one.
- Doing the assignment first forces a ton of work to happen against an anonymous type.
- While we do this, we stick in the keys of the things we're relating into a stack.
- That stack gets about 17,500 entries inserted.
- But as you relate, it's not caching.
- So you have an O(n * m) check.
- Fix is to use a map or set.
- Seems to avoid the odd regression.