Better typings for promise.race based on mapped tuple types#27192
Better typings for promise.race based on mapped tuple types#27192dubzzz wants to merge 0 commit intomicrosoft:masterfrom
Conversation
|
Actually I closed the issue because I thought that For the moment, the following code is invalid: const waitingFirst: Promise<number|string> = Promise.race([
Promise.resolve(1),
Promise.resolve(1),
Promise.resolve(1),
Promise.resolve(1),
Promise.resolve(1),
Promise.resolve("e"),
Promise.resolve(1),
Promise.resolve(1),
Promise.resolve(1),
Promise.resolve("e"),
Promise.resolve(1)
]);But it should be fixed by this PR. |
|
Wouldn't this be cleaner? interface PromiseConstructor {
// array
race<T>(values: T[]): Promise<T extends PromiseLike<infer U> ? U : T>;
// iterable
race<T>(values: Iterable<T>): Promise<T extends PromiseLike<infer U> ? U : T>;
} |
|
@rbuckton Indeed it would be cleaner. I am updating the commit accordingly |
|
Isn't array already Iterable? 🤔 |
|
@Kovensky: It is, but we split the definition between different lib files based on how much of ES2015 your host supports. |
|
@rbuckton Do I need to adapt something in this PR? |
|
@typescript-bot test this |
|
This change may be causing a compiler crash in our RWC suite. We are investigating. |
|
Please let me know when you get more details about the failure ;) |
|
Unfortunately, conditional types tend to result in higher memory usage in the compiler. One of our RWC test suites is crashing due to running out of memory as a result of this change. I will continue to investigate, but unfortunately will be out of the office next week. If this is something I am unable to address before Friday, I will continue to investigate when I return to the office. |
|
This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise. |
Following the feature - Mapped tuple types #25947 - it is now possible to have better typings for
Promise.race.