PHP 8.5 adds pipe operator

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.

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

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

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.

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 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.

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.

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...

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

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

both are going somewhere and super popular though

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

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.

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.

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.

> 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

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;

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).

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.

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.

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 =)

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.

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.

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.

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.

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.

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.

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)

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_v2 https://wiki.php.net/rfc/pipe-operator-v3#rejected_features

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?

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

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.

I'm not tempting you do to it or anything, but I want to say given your point of view, if one day you need a crude+ app and try to do it using laravel, you might be really surprised by what modern php actually is.

There was a point were I thought the language and it ecosystem was going down the drain but then they recovered and modern php is 90% what do you want to do and don't worry about the how, it's easy.

I don't use it much anymore, but every time I do all I see are possibilities.

I'll gladly praise it. It's a very practical language with good tooling and excellent amounts of libraries and scripts available. Performance is decent, development speed for tools, toys and prototypes is extreme.

The standard library has a lot of good stuff for calling API:s, handling JSON, shelling out, string juggling and HTML publishing on a socket. In every typical install you also have common database interfaces. I've done so much problem solving at breathtaking speed in single file PHP scripts and PsySH over the years.

The threading story isn't or wasn't very good so typically I've done logic in PHP and then driven it from something like a Scheme, Picolisp or Elixir when I've needed it.

This.

We definitely need a better stdlib with appropriate data structures

>The stdlib is so inconsistent this will be a nightmare.

I think that callables will end with being useless in this context and everyone will pipe closures to put that $x wherever the stdlib imposes.

Is array_map and array_filter the common argument? One works against a single element, whereas the other works against multiple. What would you suggest a better param order? Do you know that array_walk exists?

I think this is called uniform function call syntax.

That syntax is very clean when it works. I think however the limitation of not being able to pipe arguments into 2nd, 3rd, ..., positions and keyword arguments, or variadic explosion like the syntax showcased in the article makes it less powerful.

Are there other syntax helpers in that language to overcome this?

It is called Uniform [Function] Call Syntax.

D has had this for decade(s): https://tour.dlang.org/tour/en/gems/uniform-function-call-sy...

Nim too has it: https://nim-by-example.github.io/oop/

Genuine question from a non-PHP user:

Does PHP support iterator-like objects? Like Python I mean, where mydict.values() produces values on demand, not immediately realised as a list. Or are all steps necessarily guaranteed to be fully realised into a complete list?

That's how function calls work in every language. Unless it's streams.

The usual solution is to wrap it with a closure.

    function($x) { return array_key_exists('needle', $x); }

Or using the arrow function syntax:

    fn($x) => array_key_exists('needle', $x)

The same trick also helps when you need to use functions with mandatory extra parameters, functions with pass-by-value parameters, etc.

Can't the pipe operator be easily mimicked in Ruby thanks to its flexibility?

I'm thinking of something like this:

    class Object
      def |>(fn)
        fn.call(self)
      end
    end

which then can be in the following way:

    result = arr
      |> ->(a) { a.uniq }
      |> ->(a) { a.flatten }
      |> ->(a) { a.map(&:tags) }

Or if we just created an alias for then #then method:

    class Object
      alias_method :|>, :then
    end

then it can be used like in this way:

    arr
      |> :uniq.to_proc
      |> :flatten.to_proc
      |> ->(a) { a.map(&:tags) }

The trailing semi-colon on a new line helps prevent Git conflicts and gives cleaner diffs.

It's the same reason PHP allows trailing commas in all lists.

Putting the delimiter on a line of its own is a syntactical trick that helps bringing small additions down to a neater 1-line diff instead of a 2-line diff. You've probably run into it many times before in other contexts without thinking of it. Arrays/hashes, quoted multi-line strings etc.

People use Laravel Collections or similar Symfony array wrapper to achieve chaining.

Most PHP code I see look like your Ruby example.

The way function/trait resolution works in Rust, it's actually already quite idiomatic to code in this style (just using the dot operator). The standard library Iterator is a great example of this. :-)

I don't think there's any significant push for an even terser syntax at the moment.

There is the `tap` crate (https://crates.io/crates/tap) which adds `tap`, `pipe` and their variants to everything.

Backwards compatibility. The language has done a pretty amazing job at adding features over the last 10 years without really breaking a lot of old code. I believe PHP still runs about 75% of the internet, so that's pretty huge.

Because pipes work on all functions, not just object methods. So your business logic, validations etc. don't have to be methods of the built-in objects.

And there's nothing abnormal about pipes

I agree. But in PHP it would probably be like this:

$myString->trim()->replace("w", "h");

> Why not just make types psuedo-objects?

With this sort of "just" I could build Paris out of matchsticks

Because duplicating the stdlib is probably not a good idea.

> |> array_column(..., 'tags')

This syntax is invalid. But it will be possible next year with the proposed partial function application rfc

array_column(?, 'tags')

https://wiki.php.net/rfc/partial_function_application_v2

I feel like a kindergartener writing go. I wish another language got popular in the space go is used for.

Might be sooner than you think. There are already RFCs for Partial Function Application and Function Composition:

https://wiki.php.net/rfc/partial_function_application_v2 https://wiki.php.net/rfc/function-composition

I admire your conviction.

I am indeed tired of JS; however, I'm not a fan of PHP either. I like the new pipe syntax as a concept, but when added to an already uncomfortable overall programming environment, it can only provide mild relief.

You mean the fourth decade of PHP.

I'm not a fan of it, but JavaScript will outlive me.

I'd rather write JS/TS than most of the other popular languages.

one can dream but i wouldn't keep high hopes. I feel functional patterns are left as second class citizens in python.

Amen ... I mean PHP could have been such a good language if the syntax wouldn't be such a show stopper.

Thank you for your insight.

PHP is a dead language since when ?

It's so dead that 79.2% of all websites rely on PHP to some degree.

https://kinsta.com/php-market-share/

I actually don’t mind them, and I’ve been out of daily PHP work for a few years now. When I see people denote internal variables with _ or elements with $ in JS, it rubs me the wrong way, but in PHP the $ is kind of nice.

I also prefer the look of ->, it’s _cool_

I honestly don't understand this. The syntax is one of the most boring parts of a programming language. It is solved by the IDE (and now LLMs). I don't care about syntax, I care about what I can build. Since the beginning of time people argue about things like tabs vs. spaces, or the dollar sign and I honestly don't understand why that is. It just doesn't matter.

Just to be clear: consistency does very much matter. The mental load of reading totally different styles of code is awful and a waste of energy.

> Why doesn't PHP remove the horrid $ symbol for variables and the -> symbol for calling methods? I think those alone would do a lot more for its perception and adoption than adding the pipe operator.

Because it simply can't do that in a retro-compatible way. -> isn't so bad, C/C++ uses that as well. as for $ I guess it came from Perl. The point is already used for string concatenation, where other languages would overload the + operator.

Same reason C doesn't introduce classes and C++ doesn't remove pointers: it's a) part of the core language and b) extremely inconsequential for any serious developer.

I actually like the clarity these dollar signs add in a code base. Makes it easier to recognise (dynamic) functions, and makes it harder to accidentally shadow methods.

Other languages will let you do `const Math = {}` and nuke the entire math library, or write stuff like `int fopen = 0;` to make the fopen method call inaccessible in that scope. With PHP, you don't need to restrict your variable name to "something that hopefully won't conflict with an obscure method".

The -> is a leftover from an older programming language that I'd rather have replaced by a ., but not at the cost of breaking existing code (which it surely would).

Because back compat' is a very strong feature of the language, same reason "match" was created instead of replacing switch.

As a result, taking a php 5.2 script and moving it up to 8.5 is super easy, and taking a PHP 4 one is barely harder only longer (since it probably uses the horrors that were register_globals and co).

Ultimately, I prefer this than a fragmented ecosystem impossible to resolve.

The $ symbol gave me RSI as a dev just starting out. I will never forgive PHP for that. Such an unergonomic syntax.

PHP has its significant flaws, but superficial syntactic differences aren't among them. In my experience, it takes two weeks to get used to pretty much any syntax.

I though so too, but if you are using same name for various things then the whole thing can't be typechecked. Not in PHP at least. In Rust this would work perfectly with typechecking.