Implementation of pipe with existing ECMAScript features

[sharshuv-quotient]

I'm not sure if it's obvious, but it's something worth mentioning. At least for the "unary function" syntax, it is already possible to implement a pipe using functional programming principles, with a syntax that has mostly the same level of readability. RxJS are already doing that.

Here's an example of such an implementation that is supposed to work with any data type: https://stackblitz.com/edit/typescript-6z61aw?file=index.ts

Usage example:
(I'm using lodash/fp for the example)

const value = pipe([1, 2, 3], [
    map((x) => [x, x * 2]),
    flatten,
    sortBy((x) => x)
  ]
);
console.log(value); // => [1, 2, 2, 3, 4, 6]

I can understand if the proposed syntax is easier to read, and also this option only solve the case for the "unary function" proposition, but it's still something that I think is worth mentioning when thinking of how to expand the language spec.

Anyway I would love to hear some thoughts.

[noppa]

That's been discussed here quite a few times: #131, #146, #154, #164, #245
The operator in it's current Hack-style form will be more readable (ok ok I know that's debatable), more easily optimized by the engines, more "debuggable" with e.g. a step-by-step debugger, and appliable to more existing JavaScript functions, since they don't need to be unary or curried.

[js-choi]

Thanks for opening an issue; we appreciate your feedback.

In addition to the issues already mentioned in #277 (comment), this issue also seems to be a duplicate of the currently open #273. (We do still need to add this as an FAQ about this to the explainer.)

Also, a proposal for a Function.pipe function was formally made on 2022-07; it was called proposal-function-pipe-flow. It was rejected by the Committee at that time. Many Committee delegates think that Function.pipe is easily implemented in userland as a one-line function; that its problem is better solved by a Hack-like operator; and that it would encourage partial function application, which may encourage poorly optimizable code, by allocating numerous throwaway callbacks in hot paths. (See #221 regarding performance concerns by the engine implementers regarding partial function application.)

Thanks again for opening this issue; please feel free to leave comments on #273 and #221.