Description
Speed-Sensitive PRs
Definite-Assignability
- Use a definitely-assignable relation in Material-UI
- If it is a correctness fix, and it's only 1%... that's probably not so terrible.
- Will manifest in codebases where people can't really even understand the types.
- Definitely-assignable relation will never probe constraints for these.
- Isn't this just because
any
is reallyunknown
andnever
? - Maybe dual-behavior of
any
biting us.- The new relationship is about asking whether any given instantiation will break.
- Isn't this just because
- 4.2-bound if we want.
Cache Complex Union and Intersection Relations
- We have never cached the results of relations between unions and intersections.
- We only cache relations between constituents.
- Could try caching all unions/intersections.
- Made things slower in experiments.
- Does a bunch of expensive caching - bad!
- When relating
Foo | Bar | Baz
toTarget
, have to cacheFoo | Bar | Baz
toTarget
Foo
toTarget
Bar
toTarget
Baz
toTarget
- Idea: as soon as we have more than 4 targets to check against, we'll cache.
- Partial reasoning: avoiding
undefined | null | T
.
- Partial reasoning: avoiding
- This change speeds up the compilers-with-unions test case.
- Aside: any reason why compilers-with-unions was not in the perf suite?
- Was crashing, should be good now.
- Azure might be finally stable in perf numbers.
- Can we get rid of Node 8/10?
- And add Node 14/15
- Perf test fast on LTS/perf test slow
- Aside: maybe linked caches?
- 4.2-bound!
Arbitrary Index Signatures (now that we have template string types)
-
Have this old PR.
-
Would be nice to be able to model
data-
andaria-
. -
We have two "kinds" of types: finite types and infinite types
"foo"
- finite"foo" | "bar"
- finitestring
- infinite`aria-${string}`
- infinite
-
Can imagine that mapped types on
- finite types desugar to individual properties.
- infinite types remain as index signatures.
-
The PR's original motivation was symbol types.
-
As a bonus, it handled string literal types and enums.
- Those would expand out to keys.
-
Want to propose that index signatures are required to have an infinite type.
- Including pattern-literal types like
`aria-${string}`
.
- Including pattern-literal types like
-
Mapped types would be the only thing that can represent keys in a higher-order manner.
- We would not want to get into the business of
{ [x: T]: Type }
whereT
is generic. - Can't make meaningful statements about
T
in those cases.
- We would not want to get into the business of
-
We want to have a view that a mapped type can have some key type that can be finite and infinite.
- At 0-order, these types desugar as described above.
-
But we're already "equipped" to handle these.
- Index signatures are just another structural component of the type. The hard part is actually adding the index signatures.
-
Feels like we're "ripping out the foundation" to go higher-order.
-
We can ship this with 0-order.
- Shipping PR with forbidden higher-order is more code.
-
You need to be able to reason about constraints.
-
Follow-up
- Type with multiple index signatures
- Every index signature that matches, you union when reading
- Every index signature that matches, you intersect when writing
- Type with multiple index signatures
-
We have another relationship in the PR where
number
is assignable tostring
.- You could build it other ways technically.
- Could do it differently before
isRelatedTo
- But
isRelatedTo
does the nice logic.
-
What about
interface Foo { [x: `aria-${string}`]: string; [x: `aria-yadda-${string}`]: boolean; }
- Would be nice if we could provide a nice error message!
- Need to be able to relate pattern types to pattern types.
- Could imagine some set of "easier" prefix/postfix.
Partial Type Argument Inference
Out-of-time