Re: [RFC] Pipe Assignment Operator

On 16.07.26 04:07, Larry Garfield wrote:

On Thu, Jul 9, 2026, at 11:45 PM, Caleb White wrote:

Hi internals, I'd like to open discussion on my (first!) RFC for the pipe assignment operator (|>=): https://wiki.php.net/rfc/pipe_assignment_operator It adds a compound assignment form of the pipe operator, so that $x |>= callable is shorthand for $x = $x |> callable, with support for chaining. Implementation with tests is at: https://github.com/php/php-src/pull/22633 Looking forward to your feedback. Thanks! Caleb

Perhaps weirdly, I am not a huge fan of this RFC. I'm open to pipe-compound operators (the other that's been suggested is a null-safe ?|>, which I'd support), but I'm not sure of the use case for this one. That may be because, from a functional programming point of view, piping a back to itself makes little if any sense. Values should be immutable, so you would be doing $b = $a |> foo(...) |> bar(...) |> baz(...); I cannot think of a case where I would want to put $a on the left side, too. How realistic is this use case? I don't think this RFC would cause any harm, I suppose, so I probably won't vote against it. But at the moment I don't see a compelling reason to vote for it. A concrete real-world use case would help make that case, because I cannot come up with one myself. --Larry Garfield

Hey Larry, // before public function makeSlug(string $value): string {

    $value = $value |> mb_strtolower(...); // ...
    $number = $this->getNextSlugNumber($value); // checks DB
    if (0 < $number) {  $value .= "-$number";  }
    return $value;

} // after public function makeSlug(string $value): string {

    $value |>= mb_strtolower(...) ; // ...
    $number = $this->getNextSlugNumber($value); // checks DB
    if (0 < $number) {  $value .= "-$number"; }
    return $value;

} Currently we have to make assignment gymnastics even for use cases that do not require an immutable second value. Would argue many people in PHP do and will use pipes for readability, not because they suddenly write PHP from a functional programming point of view. This is a good proposal, IMO. -- Cheers Nick