Closed
Description
Variadic Tuples
Added the ability to add a "cut point" to inference to accurately describe curry
.
function curry<T extends unknown[], U extends unknown[], R>(
f: (...args: [...T, ...U]) => R,
...a: T
)
This is complicated! Why?
- You want to get the count from
...a
to know how much to cut off from [...T, ...U]` - You want
...a
to be contextually typed by whatever it could be inferred from...args
- So we now try to build up a concept of "implied arity" from these positions during the inference process.
There are some limitations around inference in certain more complex cases.
function independent<T extends unknown[], R>(
...args: [...T, (...a: T) => R]
): [T, R];
Works well for
[fixed-part, ...rest-part]
but not
[starting-fixed-part, ...rest-part, ending-fixed-part]
[...rest-part, fixed-part]
but...we think we could! Then we could model
declare const foo: string[];
independent(...foo, (...args) => hello)
- What about
pipe
?- 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.
Spreading anyTypeExpr && otherExpr
into Objects
function fn(x: unknown) {
const res = {
// 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 }),
};
}
Strange:
let x: string = (false as unknown) && "hello"; // okay
let y: string = (0 as number) && "hello"; // error
Conclusion: Try changing this behavior and see what breaks, but it sounds very breaky.
Switch to ES Maps
and Sets
- Internally we have a
Map
type, have logic that uses the native ESMap
type if available. - But the problem is, because our polyfill only worked on
string
s keys, ourMap
was limited like that all-around. - Will switch to having
K, V
. WeakMap
?- Not if we can help it, avoid using in compiler.
- What about breaking change?
- Very esoteric use-sites in our API.
- Conclusion: Try the change in beta, work with build tool authors to see impact.
Out of time