Typing varying typed rest parameters

[xeptore]

Hi!
Is there any way to type rest parameters of a function using generics?
For example:

• generalizing rxjs pipe function
• typing async series function

In general, say there is a function which receives rest parameter of functions where each one is of type <T>() => Promise<T>, and aggregate all results into a tuple, and returns it. Returned tuple item types depends on the T type parameter of each promise function. Is there any way to type such a function?

Maybe something like Promise.all(iterable)?

[millsp]

Yes, it is possible with overloads. So it's not real variation support - it's painful - but works!

https://github.com/millsp/ts-toolbelt/blob/master/sources/Function/Pipe/List/Sync.ts
https://github.com/millsp/ts-toolbelt/blob/master/sources/Function/Pipe/Multi/Async.ts

(While it works, it is not possible to generalize this from a single type. You will need to type these overloads. If you wanted to type no overloads, you'd need something to keep track of your generics while passing them around microsoft/TypeScript#1213 (comment))

So yes, typing Promise.all is certainly possible - given the two links I have give you above.

[xeptore]

The overloading solution is similar to what rxjs did for its pipe type.

Maybe this is only me who thinks Typescript compiler is magical and handle all possible scenarios, expecting it to do anything, or are there any other strongly typed language(s) that has implemented a solution to a similar problem in its world? Functional ones, etc.

btw, i will mark this thread as resolved.
Thanks for your help!

[millsp]

What do you want to type exactly? Are you trying to avoid overloads?

As far as I know, TypeScript has the most flexible type system I ever came accross.
Sure it's not perfect, but it's certainly unmatched for web dev - and it will continue improving.

[xeptore]

The function I want to type is exactly like rxjs pipe method or Promise.all(), but in a general way, which is not the case for overloads because of their limit in the number of parameters the function accepts.
As in your proposal for Higher Kind Types, I guess it is something that might be implemented in the future.