You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 type boolean, which is not assignable to the aria-${string} index signature of type string. 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.
Speed-Sensitive PRs
Definite-Assignability
#39577
any
is reallyunknown
andnever
?any
biting us.Cache Complex Union and Intersection Relations
#37910
Foo | Bar | Baz
toTarget
, have to cacheFoo | Bar | Baz
toTarget
Foo
toTarget
Bar
toTarget
Baz
toTarget
undefined | 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 }
whereT
is generic.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.
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
number
is assignable tostring
.isRelatedTo
isRelatedTo
does the nice logic.What about
Partial Type Argument Inference
#26242
Out-of-time
The text was updated successfully, but these errors were encountered: