Suggestion: Allow array of > 10 values in argument of Promise.all() and Promise.race()

[davidjenkins]

Currently, Promise.all() and Promise.race() both have signatures like this:

all<T1>(values: [T1 | PromiseLike<T1>]): Promise<[T1]>;
// ...
all<T1, T2, T3, T4, T5, T6, T7, T8, T9, T10>(values: [T1 | PromiseLike<T1>, T2 | PromiseLike<T2>, T3 | PromiseLike<T3>, T4 | PromiseLike <T4>, T5 | PromiseLike<T5>, T6 | PromiseLike<T6>, T7 | PromiseLike<T7>, T8 | PromiseLike<T8>, T9 | PromiseLike<T9>, T10 | PromiseLike<T10>]): Promise<[T1, T2, T3, T4, T5, T6, T7, T8, T9, T10]>;

While this is suitable in most cases, occasionally there is a need (or preference) to wait on the retrieval of several (10+) dependencies and then access them all within a single block.

Workarounds for Promise.all() certainly exist (i.e. splitting into multiple Promise.all() calls) - but code can become unnecessarily complex. Workarounds for Promise.race() are not as easy.

Since actual implementations of Promise.all() and Promise.race() are boundless, it would be helpful if lib.es2015.promise.d.ts reflected a wider range of plausible use cases.

Proposed solution:
Add overloads to lib.es2015.promise.d.ts - using the pattern it already uses today - to support ~20 items instead of ~10.

[dead-claudia]

This is almost a dupe of this as a subset of that bug (and an already-known one).

[jack-williams]

@isiahmeadows I feel like I'm being slow...but what does Promise.all look like with variadic generics?

[dead-claudia]

It's still a WIP feature (no set-in-stone syntax), but there are a few experimental PRs. There's a couple different concept implementations of Promise.all in that issue.

[jack-williams]

@isiahmeadows Cheers. My initial "Ctrl-F" attempts didn't expand into the collapsed comments so I missed function all<...T>(promises: [...Promise<T*>]): T;. I figured the solution might be something like that but I was just scratching my head wondering if there was a way to do it only according the initial spec with ...T.

[davidjenkins]

@isiahmeadows I completely agree, #5453 would appear to completely solve this problem, should it be accepted.

I should point out though, that while #5453 would be a complete/permanent solution, there is much more consideration that it must be given before being officially rolled out. In the meantime, lib.es2015.promise.d.ts could be extended using the pattern it already uses today - which could be accomplished in minutes - let's say to support ~20 items instead of ~10 - as a short term gap-stop while #5453 goes through the standard process of being reviewed/implemented/released.

[typescript-bot]

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.