Truly variadic pipe type

[AZMCode]

Has anyone here considered using recursive/conditional/inferred types to allow typescript to statically type the pipe function in a truly variadic way?

Here's an example of what's possible, applied to simple function composition, if only requiring some casts to achieve, but in exchange allowing for infinitely large truly variadic pipe:

type PipeReturn<Rest extends ((x: any) => any)[]> =
    Rest extends [infer F1 extends (x: any) => any,infer F2 extends (x: any) => any, ...infer RestTail extends ((x: any) => any)[]] ?
        ReturnType<F1> extends Parameters<F2>[0] ?
            PipeReturn<[(x: Parameters<F1>[0]) => ReturnType<F2>,...RestTail]> :
            never :
        Rest extends [(x: infer A) => infer B] ?
            (x: A) => B :
            Rest extends [] ?
                <T>(x: T) => T :
                ((x: any) => any)
    ;


function pipe<F extends ((x: any) => any)[]>(...fs: F): PipeReturn<F> {
    if(fs.length === 0) return (<T>(x: T) => x) as PipeReturn<F>;
    if(fs.length === 1) return fs[0] as PipeReturn<F>;
    const [f,...rest] = fs;
    return ((x: any) => f(pipe(...rest))) as PipeReturn<F>;
} 

This typechecks in typescript 5.4.5

To clarify my point, despite using any everywhere in the type definition, this makes the pipe function be truly variadic, using type recursion. Ensuring type safety between the return type of the previous function and parameter of the nextfunction, using conditional and inferred types. The case where the length of the function tuple is not known is covered by a default (x: any) => any in the last branch, but this could be changed to anything.

The only real downside I can see to this is probably my poorly-performing pipe function implementation, which can be changed to the existing definition if needed, and lacking support for older typescript versions that don't have these features.

I'm sure a similar approach could be used for Operators, as defined in this library.
I can start work on it if the author deems it useful enough.

[vitaly-t]

I'm not sure I see what's this about, without any practical examples. The pipe implementation here is already variadic, and passes output type from one operator to the input of the next, and it works perfectly fine.

[AZMCode]

I quote the code here:

interface PipeSync {
    <T extends Iterable<unknown>>(
        i: T
    ): T extends Iterable<infer E> ? IterableExt<E> : never;

    <T extends Iterable<unknown>, A>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>
    ): IterableExt<A>;

    <T extends Iterable<unknown>, A, B>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>
    ): IterableExt<B>;

    <T extends Iterable<unknown>, A, B, C>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>,
        p2: Operation<B, C>
    ): IterableExt<C>;

    <T extends Iterable<unknown>, A, B, C, D>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>,
        p2: Operation<B, C>,
        p3: Operation<C, D>
    ): IterableExt<D>;

    <T extends Iterable<unknown>, A, B, C, D, E>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>,
        p2: Operation<B, C>,
        p3: Operation<C, D>,
        p4: Operation<D, E>
    ): IterableExt<E>;

    <T extends Iterable<unknown>, A, B, C, D, E, F>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>,
        p2: Operation<B, C>,
        p3: Operation<C, D>,
        p4: Operation<D, E>,
        p5: Operation<E, F>
    ): IterableExt<F>;

    <T extends Iterable<unknown>, A, B, C, D, E, F, G>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>,
        p2: Operation<B, C>,
        p3: Operation<C, D>,
        p4: Operation<D, E>,
        p5: Operation<E, F>,
        p6: Operation<F, G>
    ): IterableExt<G>;

    <T extends Iterable<unknown>, A, B, C, D, E, F, G, H>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>,
        p2: Operation<B, C>,
        p3: Operation<C, D>,
        p4: Operation<D, E>,
        p5: Operation<E, F>,
        p6: Operation<F, G>,
        p7: Operation<G, H>
    ): IterableExt<H>;

    <T extends Iterable<unknown>, A, B, C, D, E, F, G, H, I>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>,
        p2: Operation<B, C>,
        p3: Operation<C, D>,
        p4: Operation<D, E>,
        p5: Operation<E, F>,
        p6: Operation<F, G>,
        p7: Operation<G, H>,
        p8: Operation<H, I>
    ): IterableExt<I>;

    <T extends Iterable<unknown>, A, B, C, D, E, F, G, H, I, J>(
        i: T,
        p0: Operation<T extends Iterable<infer E> ? E : never, A>,
        p1: Operation<A, B>,
        p2: Operation<B, C>,
        p3: Operation<C, D>,
        p4: Operation<D, E>,
        p5: Operation<E, F>,
        p6: Operation<F, G>,
        p7: Operation<G, H>,
        p8: Operation<H, I>,
        p9: Operation<I, J>
    ): IterableExt<J>;

    (
        i: Iterable<unknown>,
        ...p: readonly Operation<unknown, unknown>[]
    ): IterableExt<unknown>;
}

The pipe operation typings only support strict type checking up to 10 operations, after which nesting the invocations or unknown types have to be accepted.

My code is certainly not perfect (working on removing the any types as we speak) but the possibility of supporting any number of operations while preserving type checking was intriguing enough in my opinion to ask about it.

[vitaly-t]

Pipes here support recursion and extension, so the chances of 10 operators being not enough are too small.

i.e. you can pipe a stream, and then re-pipe it indefinitely, or you can have sub-pipes.

And there's hardly any real-world example where 10 operators would not be enough. I've never seen one.

[AZMCode]

Since I have a discussion to post from, and even though this probably won't get anywhere close to reasonable for a couple reasons I'll explain later, Here's a streamlined version, applied to pipeSync specifically:

type PipeSyncReturn<T,Ops extends Operation<unknown,unknown>[]> =
    Ops extends [] ?
        IterableExt<T> :
    Ops extends [Operation<T,infer U>] ?
        IterableExt<U> :
    Ops extends [Operation<T,infer U1>,Operation<infer U2,infer V>, ...infer Rest extends Operation<unknown,unknown>[]] ?
        (
            U2 extends U1 ?
                PipeSyncReturn<V,Rest> :
                never
        ):
    IterableExt<unknown>

export function pipeSync<T,Ops extends Operation<unknown,unknown>[]>(
    i: Iterable<T>,
    ...p: Ops
): PipeSyncReturn<T,Ops> {
    if (isAsyncIterable(i)) {
        throw new TypeError(
            'Cannot run the sync pipeline from an AsyncIterable'
        );
    }
    return extendIterable(p.reduce((c, a: any) => a(c), optimizeIterable(i)));
}

This version type-checks correctly with a notable exception. The return type is inferred to be never if the types of the operators mismatch.
This is because currently typescript doesn't support invalid types, meaning the pipe function will simply infer never as the return type when it should error on typechecking. However, if and when typescript implements this feature, this could be feasible.

Regardless, due to this limitation this approach probably won't get far without this feature.

On the subject of practicality, absolutely. There are near to none cases where this would be useful where simply recursing or nesting wouldn't be appropriate. I did it just for fun I guess. I apologize for going straight to an issue nevertheless, should've started with the discussion. Thanks for humoring me regardless.

[vitaly-t]

Thank you for your contribution! This project was fully finished some time ago, as production-ready, and at this point I can only allocate time for bug fixing. In the meantime, see iter-ops-extras for many custom operators.

However, if and when typescript implements this feature, this could be feasible.

That proposal is now 6 years old, so I wouldn't hold your breath on this.

[vitaly-t]

I didn't mean to close it, but chances of further development in this direction are slim to none. I can only address bugs at this point, or add something into iter-ops-extras.