Description Speed-Sensitive PRs
Definite-Assignability
#39577
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 really unknown and never?
Maybe dual-behavior of any biting us.
The new relationship is about asking whether any given instantiation will break.
4.2-bound if we want.
Cache Complex Union and Intersection Relations
#37910
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 to Target, have to cache
Foo | Bar | Baz to Target
Foo to Target
Bar to Target
Baz to Target
Idea: as soon as we have more than 4 targets to check against, we'll cache.
Partial reasoning: avoiding undefined | null | T.
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)
#26797
Have this old PR.
Would be nice to be able to model data- and aria-.
We have two "kinds" of types: finite types and infinite types
"foo" - finite
"foo" | "bar" - finite
string - 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}`.
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 } where T is generic.
Can't make meaningful statements about T in those cases.
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
We have another relationship in the PR where number is assignable to string.
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
#26242
Out-of-time
Reactions are currently unavailable
You can’t perform that action at this time.
Speed-Sensitive PRs
Definite-Assignability
#39577
anyis reallyunknownandnever?anybiting us.Cache Complex Union and Intersection Relations
#37910
Foo | Bar | BaztoTarget, have to cacheFoo | Bar | BaztoTargetFootoTargetBartoTargetBaztoTargetundefined | null | T.Arbitrary Index Signatures (now that we have template string types)
#26797
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}`- infiniteCan imagine that mapped types on
The PR's original motivation was symbol types.
As a bonus, it handled string literal types and enums.
Want to propose that index signatures are required to have an infinite type.
`aria-${string}`.Mapped types would be the only thing that can represent keys in a higher-order manner.
{ [x: T]: Type }whereTis generic.Tin those cases.We want to have a view that a mapped type can have some key type that can be finite and infinite.
But we're already "equipped" to handle these.
Feels like we're "ripping out the foundation" to go higher-order.
We can ship this with 0-order.
You need to be able to reason about constraints.
Follow-up
We have another relationship in the PR where
numberis assignable tostring.isRelatedToisRelatedTodoes the nice logic.What about
Partial Type Argument Inference
#26242
Out-of-time