F# is excellent. It’s tooling, ecosystem, and compile times are the reason I don’t use it. I learned it alongside OCaml, and OCaml’s compilation speed spoiled me.

It is indeed a shame that F# never became a first class citizen.

There are also ||> and |||> for automatically destructuring tuples and passing each part as a separate value along.

And there are also the reverse pipes (<|, <|| and <|||)

F# is, for me, the single most ergonomic language to work in. But yeah, M$ isn't investing in it, so there are very few oppurtunities to actually work with f# in the industry either.

It's kind of wild that PHP gets a pipe(line) operator before JS finalizes its' version... of course they've had multiple competing proposals, of which I liked the F# inspired one the most... I've stopped relying on the likes of Babel (too much bloat) or I'd like to be able to use it. I used it for years for async functions and module syntax before they were implemented in node and browsers. Now it's hard to justify.

Is |> actually an operator in F#? I think it's just a regular function in the standard library but maybe I'm remembering incorrectly.

Haskell seems pretty dead as well. Good think php has another option for line noise though.

Not only have we been waiting for 10 years, the most likely candidate to go forward is not at all what we wanted when the proposal was created:

We wanted a pipe operator that would pair well with unary functions (like those created by partial function application, which could get its own syntax), but that got rejected on the premise that it would lead to a programming style that utilizes too many closures[0], and which could divide the ecosystem[1].

Yet somehow PHP was not limited by these hypotheticals, and simply gave people the feature they wanted, in exactly the form it makes most sense in.

[0]: https://github.com/tc39/proposal-pipeline-operator/issues/22... [1]: https://github.com/tc39/proposal-pipeline-operator/issues/23...

It’s really not needed, syntax sugar. With dots you do almost the same. Php doesn’t have chaining. Adding more and more complexity doesn’t make a language better.

Good- the [real world examples of pipes in js](https://github.com/tc39/proposal-pipeline-operator?tab=readm...) are deeply underwhelming IMO.

Sadly they went obsessing over pipes with promises which don't fit the natural flow.

Go explain them that promises already have a natural way to chain operations through the "then" method, and don't need to fit the pipe operator to do more than needed.

in typescript we can do this

let res res = op1() res = op2(res.op1) res = op3(res.op2)

type inference works great, and it is very easy to debug and refactor. In my opinion even more than piping results.

Javascript has enough features.

Best you'll git will be 3 new build systems and 10 new frameworks

do not let me start on monads in golang...

both are going somewhere and super popular though

The problem with intermediate assignment is that they pollute your scope.

You might have $values and then you transform it into $b, $values2, $foo, $whatever, and your code has to be eternally vigilant that it never accidentally refers to $values or any of the intermediate variables ever again since they only existed in service to produce some downstream result.

Sometimes this is slightly better in languages that let you repeatedly shadow variables, `$values = xform1($values)`, but we can do better.

That it's hard to name intermediate values is only a symptom of the problem where many intermediate values only exist as ephemeral immediate state.

Pipeline style code is a nice general way to keep the top level clean.

    {
        $foo = 'bar'; // only defined in this block
    }

I don't disagree with you. I had trouble reading the examples at first. But what immediately struck me is this syntax is pretty much identical to chaining object methods that return values.

  $result = $obj->query($sqlQuery)->fetchAll()[$key]

so while the syntax is not my favorite, it at least maintains consistency between method chaining and now function chaining (by pipe).

It reads well to me, as someone familiar with Perl map and jq lambda. But I would syntactic sugar it rather more strongly using a new `|=>` operator implying a distributive `|>` into its now-inferred-and-silent => arguments:

    $result = $arr |> fn($x) |=>
        array_column($x, 'values'),
        array_merge(...$x),
        array_reduce($x, fn($carry, $item) => $carry + $item, 0),
        str_repeat('x', $x);

As teaching the parser to distribute `fn($x) |=> ELEM1, ELEM2` into `fn($x) => ELEM1 |> fn($x) => ELEM2 |> …` so that the user isn’t wasting time repeating it is exactly the sort of thing I love from Perl, and it’s more plainly clear what it’s doing — and in what order, without having to unwrap parens — without interfering with any successive |> blocks that might have different needs.

Of course, since I come from Perl, that lends itself well to cleaning up the array rollup in the middle using a reduce pipe, and then replacing all the words with operators to make incomprehensible gibberish but no longer needing to care about $x at all:

    $result = $arr |> $x:
        ||> 'values'
        |+< $i: $x + $i
        |> str_repeat('x', $x);

Which rolls up nicely into a one-liner that is completely comprehensible if you know that | is column, + is merge, < is reduce, and have the : represent the syntactic sugar for conserving repetitions of fn($x) into $x using a stable syntax that the reduce can also take advantage of:

    $result = $arr |> $x: ||> 'values' |+< $i: $x + $i |> str_repeat('x', $x);

Which reads as a nice simple sentence, since I grew up on Perl, that can be interpreted at a glance because it fits within a glance!

So. I wouldn’t necessarily implement everything I can see possible here, because Perl proved that the space of people willing to parse symbols rather than words is not the complete programmer space. But I do stand by the helpfulness of the switch-like |=> as defined above =)

This is what a good IDE brings to the table, it'll show that $result is of type string.

The pipe operator (including T_BLING) was one of the few things I enjoyed when writing Hack at Meta.

You're conflating different concepts: familiarity and simplicity.

I don't find the pipe alternative to be much harder to read, but I'd also favour the first one.

In any case, we shouldn't judge software and it's features on familiarity.

I don’t disagree with your reasoning but I would have thought this pipe would be in an appropriately named function (at least that’s how I’d use it in Elixir) to help understand the result.

> I think the syntax is much more complicated to read, requiring backtracking to understand.

Same as with `array_merge(...array_column($arr, 'values'));` or similar nested function calls.

> Imagine you're just scanning code you're unfamiliar with trying to identify the symbols. Make sense of inputs and outputs, and you come to something as follows.

We don't have to imagine :) People working in languages supporting pipes look at similar code all day long.

> but the self-documentating nature of a couple variables defining what things are or are doing seems important to writing maintainable code

Pipes do not prevent you from using a couple of variables.

In your example I need to keep track of $values variable, see where it's used, unwrap nested function calls etc.

Or I can just look at the sequential function calls.

What PHP should've done though is just pass the piped value as the first argument of any function. Then it would be much cleaner:

  $result = $arr
    |> array_column('values')
    |> array_merge()
    |> array_reduce(fn($carry, $item) => $carry + $item, 0)
    |> fn($x) => str_repeat('x', $x);

I wouldn't be surprised if that's what will eventually happen

People use method chaining all the time and don't have any issue with it? It's equivalent to something like:

    $result = $arr
        ->column('values')
        ->merge()
        ->reduce(fn($carry, $item) => $carry + $item, 0)
        ->repeat('x');

I think this just comes down to familiarity.

I think it's more a matter of what you're used to. It's simply an operator and syntax that you aren't used to seeing. Like if they added back a character into English that you aren't familiar with and started using it in words that you no longer recognize.

A lot of people could say the same of the rest/spread syntax as well.

I completely agree about intermediate variables (and with explicit type annotations in a typed language) to make the code more intelligible.

But maybe also, the pipe syntax would be better as:

    $arr
    |> fn($x) => array_column($x, 'values')
    |> fn($x) => array_merge(...$x)
    |> fn($x) => array_reduce($x, fn($carry, $item) => $carry + $item, 0)
    |> fn($x) => str_repeat('x', $x)
    |= $result;

It's no different than chained property accesses or method calls, or more generally nested expressions. Which is to say, if you overuse it, you hamper readability, but if you have a named result for every single operation, it is also hard to read because it introduces too much noise.

Kotlin also has extensions function `let` (and a couple of variants) which let you chain arbitrary methods:

``` val arr = ... val result = arr .let { column(it, "tags") .let { merge(it) } .let { unique(it) } .let { values(it) } ```

You add function references for single-argument functions too:

``` arr.let(::unique) // or (List<>::unique), depends on the function ```

all without adding a special language construct.

The advantage is that pipes don't care about the type of the return value.

Let's say you add a reduce in the middle of that chain. With extension methods that would be the last one you call in the chain. With pipes you'd just pipe the result into the next function

PHP has traits, just invent that API, put it in a trait and add it to your data classes.

  $sum = [1, 2, 3]->filter(fn($x) => $x%2!= 0)->concat([5,7])->sum();

Basically what Collections do in Laravel.

I don't see how this is hard to reason about, assuming this is the resulting code when using variables:

  $tags        = ...array_column($arr, 'tags');
  $merged_tags = array_merge($tags);
  $unique_tags = array_unique($merged_tags);
  $tag_values  = array_values($unique_tags);

It also makes it easier to inspect the values after each step.

> It's so much easier to reason about

Is it though? I don't think so.

Apparently "foo(...)" is just the PHP syntax for a function reference, according to the "first-class callable" RFC [1] linked from the article.

So where in Python you would say e.g.

  callbacks = [f, g]

PHP requires the syntax

  $callbacks = [f(...), g(...)];

As for the purpose of the feature as a whole, although it seems like it could be replaced with function composition as mentioned at the end of the article, and the function composition could be implemented with a utility function instead of dedicated syntax, the advantage of adding these operators is apparently [2] performance (fewer function calls) and facilitating static type-checking.

[1] https://wiki.php.net/rfc/first_class_callable_syntax

[2] https://wiki.php.net/rfc/function-composition#why_in_the_eng...

There is a complementary RFC for partial function application which will allow calling a function with more than one parameter.

https://wiki.php.net/rfc/partial_function_application_v2https://wiki.php.net/rfc/pipe-operator-v3#rejected_features

It is to interject the chained value at the right position in the function.

They write that elixir has a slightly fancier version, it is likely around this, they mean (where elixir has first class support for arity > 1 functions)

The syntax could be improved by allowing you to omit the (...) part entirely for single argument functions and using currying for functions that need additional arguments. So you would end up with something like:

  $result = $arr
      |> select_column('tags')         // Gets an array of arrays
      |> fn($x) => array_merge(...$x)  // Flatten into one big array
      |> array_unique                  // Remove duplicates
      |> array_value                   // Reindex the array.

Agree, the ... syntax feels confusing when each fn($x) in the example uses $x as the name of its argument.

My initial instinct would be to write like this:

`$result = $arr

    |> fn($arr) => array_column($arr, 'tags') // Gets an array of arrays

    |> fn($cols) => array_merge(...$cols)`

Which makes me wonder how this handles scope. I'd imagine the interior of some chained function can't reference the input $arr, right? Does it allow pass by reference?

     function ($parameter) use ($data) { ... }

   > $stuff = [1]
   = [
       1,
     ]

   > $fn = function ($par) use (&$stuff) { $stuff[] = $par; }
   = Closure($par) {#3980 …2}

   > $fn(2)
   = null

   > $stuff
   = [
       1,
       2,
     ]

PHP string / array functions are consistent.

string functions use (haystack, needle) and array functions use (needle, haystack)

because that's the way the underlying C libraries also worked