The "Pipeline" Operator - Making multiple function calls look great

Alican Çubukçuoğlu alicancubukcuoglu at
Sun Dec 13 02:49:32 UTC 2015

This is a terrible example. It looks a lot better with what's already
async function runTask () {
  const file = await fs.readFile('./index.txt');

  const all = await* file


Also how do you explain this feature to a newbie? This operator is supposed
to call the function at the RHS with the value at the LHS and now it also
has a special case when there is `await` at the RHS. How more complicated
will this proposal get for the sake of making it look useful?

This proposal's aim should basically be turning this:
into this:
myVar |> myFunc;

If it is not useful by just doing that then it should simply be rejected.


About the usefulness of this proposal, this one conflicts with the function
bind syntax and assuming FBS is all rainbows and unicorns and everyone
should use it, then this proposal makes no sense since the original example
should be written like this (and it's already good enough):
function doubleSay () {
  return this + ', ' + this;
function capitalize () {
  return this[0].toUpperCase() + this.substring(1);
function exclaim () {
  return this + '!';

const result = 'hello'
  ::exclaim(); // "Hello, hello!"

It's also weird that how the RHS of PO become weird when the function takes
extra parameters. You can see how the code becomes polluted:
// Have fbFunc) with 0 parameters

// Add a parameter to fbsFunc()

// Have opFunc() with 0 parameters
citizen |> opFunc;

// Add a parameter to opFunc()
citizen |> _ => opFunc(_, param);

So we would be lying if we said the PO syntax is `param |> func`.

The reality is:
// FBS syntax:

// PO syntax:
param1 |> _ => opFunc(_, param2);

This is no good.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list