Define an operator for tuples (n-arity) pipeline

[dustbort]

As this proposal addresses a scalar (1-argument) pipeline, can we also have an operator to for an n-argument pipeline?

For example, call the operator |>>. Then we can write

[1, 2, 3] |>> funcOnThreeArgs

which is equivalent to

[1, 2, 3] |> (args) => funcOnThreeArgs(...args)

It seems like it should be possible to avoid defining operators for each arity as in F# ( |>, ||>, |||>, <|, <||, <||| ), but maybe someone can explain if this is not the case. Regarding TypeScript, as long as the functions in the pipeline return a tuple type instead of an array type, TypeScript can type-check the arity of each step without using an arity-specific operator. (This does not say that all steps must have the same arity.)

One question (which also applies to the proposed |>) is how arity mismatch should be handled. For example, when providing fewer arguments than the function's arity:

[1, 2] |>> (a, b, c) => a*a + b*b === c*c

Should this

1. apply as [1, 2, undefined];
2. apply as an implicit partial application, as if the function were (a, b) => (c) => a*a + b*b === c*c ; or
3. cause an error?

(1) is consistent with the existing argument spread syntax. Similarly, argument spread syntax handles too may arguments by ignoring the extra args.

If accepted, other variants that apply to scalar pipeline |> would equally apply to tuple pipeline |>>, such as optional chaining.

[dustbort]

On second thought we don't need this very much, since we have tuple destructuring.

[noppa]

In the first step of the pipeline, [1, 2] ||> foo can always be replaced with just foo(1, 2), so this would mainly be useful in cases where step n of the pipeline returns an array/tuple and step n + 1 expects the values of that array as arguments. That doesn't sound very common use case to me, and in cases where that is needed, one can always either resort to "manually" wrapping the function to be called |> ([a, b]) => foo(a, b), or use a helper like _.spread |> spread(foo).

IMHO given that even the minimal version of this proposal has been in a stalemate for years, the bar should be pretty high for adding new variants/features to it.

[bjunc]

I think this falls into a category of discussion that I have noticed a lot of, which is to try and get the pipe to be a swiss army knife. In most cases, the "problems" I see trying to be solved are easily addressed by wrapping in an anonymous function.