PHP 8.5 adds pipe operator

JS vs PHP pipelines

• Many compare PHP’s new pipe to JavaScript’s stalled pipeline proposal, noting JS has debated it for ~10 years without standardizing, partly over performance and style concerns.
• Some argue JS committees block useful features (pipelines, proper tail calls, records/tuples) while shipping less impactful ones, and that performance is used inconsistently as a veto.
• Others defend JS engine teams, saying complex cases (multiple-argument pipelines) imply many closures and real perf issues.

Pipes vs method chaining / extension methods

• One camp prefers extension/iterator APIs (Kotlin, C#, Laravel collections) or uniform function call syntax: arr.column('tags').flatten().unique().values().
• Pipe advocates say chaining forces everything into one class/type and leaks abstractions; pipes compose arbitrary functions, regardless of return type, with less boilerplate and easier extension.
• Traits and wrapper collection classes are suggested as partial workarounds but don’t cover primitives/arrays cleanly and can cause conflicts between libraries.

PHP pipe semantics and limitations

• Pipe passes the previous result as the single required parameter to the next callable and always as the first argument; argument position can’t be changed.
• Built-ins that take no params can’t be piped; userland functions silently ignore extra args, which some find odd.
• Because of PHP’s inconsistent parameter order (e.g., array_filter(arr, cb) vs array_map(cb, arr)), people expect to wrap many stdlib calls in lambdas.
• The foo(...) syntax is just “first-class callable” notation, which confuses some; lambdas are currently needed where partial application (fn(?, 'tags')) would help. Related RFCs for partial application and function composition are referenced.

Readability, maintainability, and style

• Supporters say pipes linearize nested calls, reduce naming of throwaway intermediates, and avoid polluting scope, making skimming easier.
• Skeptics find long pipelines harder to read and reason about, especially when trying to understand “what is this variable?” rather than “how was it derived”; they prefer a few well-named temporaries or small helper functions.
• Some worry about pass‑by‑reference inside pipelines making behavior harder to reason about.

Performance and “real pipe” expectations

• Several note each step still buffers a full result—unlike shell pipes—unless iterators/generators are used explicitly.
• Others respond that this is how normal function calls work in most languages and that pipeline sugar doesn’t change that.

PHP syntax, stdlib design, and perception

• The pipe is widely welcomed as a modern, functional feature; people mention Elixir, F#, Clojure, Raku, D, Nim, etc. as prior art.
• Some complain the syntax (|>, ..., $, ->, \ for namespaces) is ugly or unergonomic; others argue syntax is minor compared to capabilities and that backward compatibility prevents large changes.
• There’s recurring frustration with PHP’s inconsistent string/array APIs and weak Unicode support; some think improving stdlib and primitives would matter more than adding pipes.
• Overall sentiment: mixture of cautious skepticism about ergonomics and strong appreciation that PHP continues to evolve in a functional direction.