Improve rest Generics in 3.0 RC sufficiently to support RxJS Observable.prototype.pipe

Search Terms

variadic pipe rxjs

Suggestion

Improve variadic kind support to allow determining the final part of the kind in some way. The problem is currently in 3.0-rc, I haven’t found a way to improve RxJS’s pipe method. There are a lot of people using TypeScript with RxJS and this has been a pain point for all of them.

Maybe some sort of syntax like:

declare type OperatorFunction<T, R> = (source: Observable<T>) => Observable<R>;

class Observable<T> {
  pipe<R, U extends [OperatorFunction<T, any>, ...OperatorFunction<any, any>[], OperatorFunction<any, R>]>(...operators: U): Observable<R>; 
}

It’s a tricky case because type inferance also has to work.

Use Cases

RxJS currently has a lot of overloads just to support what is really a common functional programming feat.

Examples

Mostly I’d use this as shown above to define the pipe method on Observable.

Really I’m looking for any solution to this problem though. It’s a very common complaint from our TypeScript users.

🙏

Checklist

My suggestion meets these guidelines:

• This wouldn’t be a breaking change in existing TypeScript / JavaScript code
• This wouldn’t change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn’t a runtime feature (e.g. new expression-level syntax)

[ahejlsberg]

@benlesh Much as I share your distaste for walls of overloads, this actually seems like a case where it is merited. The manner in which types flow from the output of one argument to the input of the next would be really hard to capture in a single higher-order construct (and, to be sure, there are just so many different ways the types might flow that elevating a single pattern to a new construct seems questionable).

Beyond the issue of only handling a fixed maximum number of arguments, what are the issues caused by the overload pattern? I’m curious about the specific pain point you refer to.

[DanielRosenwasser]

#24897 didn’t claim to solve everything in #5453, and I don’t think we’re expecting any new changes in 3.0, but we’ll be continuing to think about solutions for variadic types.

That doesn’t mean this problem won’t get solved in another 3.x release though, so hopefully you don’t think you’re running out of time or anything like that.