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
Activity
weswigham commentedon Oct 30, 2020
@DanielRosenwasser if you're curious for a case of how higher order index types become useful, consider the validation case:
offers validation that all the possible properties produced by the second index signature are assignable to the index signature type (if the possible values overlap, which they do). Imagine we had instead written:
the compiler would be able to warn us of our mistake -
aria-busy
is of typeboolean
, which is not assignable to thearia-${string}
index signature of typestring
. Whereas the equivalent mapped type:would have no such validation, and simply produce a
never
upon reading each of the specified properties. There are usability reasons why generic index signatures should exist. Mapped types are definitely more powerful - the 1-to-1 correspondences they represent allow for powerful remappings of both keys, values, and modifiers, none of which are something an index signature could reasonably do without constraining when it could do them in strange ways, while index signatures play an important role in ensuring object consistency and intent - the same way overload signatures need to be consistent with the implementation.