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
Base tsconfigs
Abstract Constructor Types
Metadata
Metadata
Assignees
Type
Projects
Milestone
Relationships
Development
No branches or pull requests
Activity
awerlogus commentedon Jun 21, 2020
The best way to implement
pipe
without of overload pyramids is #38182. But as I see, nobody still really interested in this.