Based on the examples given in the blog post, this appears to be a massive step backwards for PHP. The language has been making an effort to clean itself up for years. The author claims that the temporary variable solution "feels icky". If we ultimately care about readability and performance, temporary variables seem ideal even with this change in the language. Modern compilers look for things like temporary variables when performing optimizations. PHP's compiler probably already does this, and if it doesn't, adding support for that would make more sense than adding some new syntax.
I'm not complaining, and I respect the PHP team for continuing to try to improve the language, but I think that we might have passed the point where new additions to the language actually make it worse.
I feel like if you treat temporary variables as documentation they feel less icky. All these examples with the pipeline operator cause way more mental overhead than reading temporary variable names.
I think it really depends on what operations you are applying. Having one succinct named variable like $slug with a few simple pipeline calls like in the example is "self-documenting" and easy to read. However, some lambdas and non-standard function are definitely a place for nicely named temporary variables in my opinion.
Kind of a clunky and verbose syntax at the moment. I wonder what languages get pipe syntax right?
Obligatory: Raku supports pipe in both directions, passing input as the last parameter instead of requiring the function to take only one parameter. It also has a shorthand:
my @array = <7 8 9 0 1 2 4 3 5 6 7 8 9>;
my @final-array = @array.unique.sort.reverse;
say @final-array;
There is a complementary Partial Function Application RFC which, among other things, solves the one-parameter limitation. It allows a question mark to be substituted in for the piped value:
8.5 notably includes the new pipe operator: https://stitcher.io/blog/pipe-operator-in-php-85
Based on the examples given in the blog post, this appears to be a massive step backwards for PHP. The language has been making an effort to clean itself up for years. The author claims that the temporary variable solution "feels icky". If we ultimately care about readability and performance, temporary variables seem ideal even with this change in the language. Modern compilers look for things like temporary variables when performing optimizations. PHP's compiler probably already does this, and if it doesn't, adding support for that would make more sense than adding some new syntax.
I'm not complaining, and I respect the PHP team for continuing to try to improve the language, but I think that we might have passed the point where new additions to the language actually make it worse.
I feel like if you treat temporary variables as documentation they feel less icky. All these examples with the pipeline operator cause way more mental overhead than reading temporary variable names.
I think it really depends on what operations you are applying. Having one succinct named variable like $slug with a few simple pipeline calls like in the example is "self-documenting" and easy to read. However, some lambdas and non-standard function are definitely a place for nicely named temporary variables in my opinion.
Kind of a clunky and verbose syntax at the moment. I wonder what languages get pipe syntax right?
Obligatory: Raku supports pipe in both directions, passing input as the last parameter instead of requiring the function to take only one parameter. It also has a shorthand:
my @array = <7 8 9 0 1 2 4 3 5 6 7 8 9>; my @final-array = @array.unique.sort.reverse; say @final-array;
There is a complementary Partial Function Application RFC which, among other things, solves the one-parameter limitation. It allows a question mark to be substituted in for the piped value:
$foo |> str_replace('hello', 'hi', ?);
https://wiki.php.net/rfc/partial_function_application_v2
Great news! PHP is going to humiliate all its haters.
Still PHP's syntax leaves much to be desired, especially the arrays. https://waspdev.com/articles/2025-06-12/my-honest-opinion-ab...
Still no unicode support? What in the hell are the devs doing? Looks like they still force that nasty mb_real_uppercase and pals on you.
Maybe waiting for a major version, perhaps 9.0… hopefully.
Not that I have any skin in that game anymore; I moved my stack from PHP years ago.
And yet millions of websites built on PHP happily serve unicode content to billions of users. Strange.
What do you mean? It was released with PHP 6.0 /s