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
Common, but is very complicated to type without pyramids of overloads.
There's also compose which is more right to left, which we couldn't do.
Wasn't within scope for this PR.
Maybe potential in the future, but also, maybe |> is the better solution.
We had some questions about applying mapped type transformations across different places.
Turns out that we don't encode the right information to say that when constrained to a union of array/tuple types, a homomorphic mapped type will also be array/tuple-like.
Instead, we just assume that the thing is more plain object-like than array-like.
Basically the same as behavior of mapped types on arrays before they were special-cased in around TS2.9ish.
functionfn(x: unknown){constres={// uh oh!// 'prop' is specified more than once, so this usage will be overwritten.prop: 100,// This spread always overwrites this property.
...(x&&{prop: 200}),};}
Variadic Tuples
#39094
Added the ability to add a "cut point" to inference to accurately describe
curry
.This is complicated! Why?
...a
to know how much to cut off from [...T, ...U]`...a
to be contextually typed by whatever it could be inferred from...args
There are some limitations around inference in certain more complex cases.
Works well for
but not
but...we think we could! Then we could model
pipe
?|>
is the better solution.Spreading
anyTypeExpr && otherExpr
into Objects#39113
Strange:
Conclusion: Try changing this behavior and see what breaks, but it sounds very breaky.
Switch to ES
Maps
andSets
#33771
Map
type, have logic that uses the native ESMap
type if available.string
s keys, ourMap
was limited like that all-around.K, V
.WeakMap
?Out of time
Base tsconfigs
tsconfig/bases#15
Abstract Constructor Types
#36392
The text was updated successfully, but these errors were encountered: