Let me try to rephrase Larry's idea.
The pipe operator made its way into PHP from functional programming
languages, where immutability is a key aspect of the language's
behavior. In those languages, it enables code that is both more
productive and freer from side effects.
The goal of bringing such operators into PHP is to enhance the
language's predictability and minimize side effects, gradually shifting
the coding style from imperative to more functional—rather than simply
providing a bit of convenient syntactic sugar.
Attempting to transform such an operator from an immutable, functional
construct into a mutable, imperative one steers the language in the
wrong direction and undoes previous efforts.
Therefore, the ability to simplify the expression
`$params['current']['pallet_cost'] =
floatval($params['current']['pallet_cost'])` does not actually improve
this code. This code and other examples are initially designed to mutate
the original array rather than returning a new one with corrected types.
It also uses `floatval`/`intval` instead of the faster native type casts
`(float)`/`(int)`. If you rewrite this code using native casts, the pipe
won't be applicable to this case at all.
You’re pointing to the Laravel experience. But in Laravel, most
operations involving collections (with the exception of `transform`,
where it is explicitly stated otherwise) and arrays (using the `Arr`
helper) are actually performed immutably. Those helpers for immutability
and method chaining were introduced in Laravel a long time ago precisely
because the language lacked convenient built-in tools for such tasks.
If you want mutability, you can always intoroduce a helper in a specific
project.
```
function apply(&$value, callable $callback) {
return $value = $callback($value);
}
```
аnd call
```
apply($params['current']['pallet_cost'], floatval(...));
```
You also cite the example `$model |>= ltrim(?)` and compare it to `$x .=
'yyy'`, but the scenarios are different. In `$x .= 'yyy'`, the
right-hand side doesn't depend on `$x`, so there’s no cognitive
overhead. In `$model |>= ltrim(?)`, however, the right-hand side depends
on the variable from the left via the `?` placeholder, creating a
mind-bending circular dependency. `$model` goes into `ltrim` and then
comes back out; that is far more convoluted than simply appending to a
string or incrementing/decrementing a value. That is likely why
assignment operators like `.=`, `+=`, and `-=` are used much more
frequently than others—they are easier to grasp than an operation like
`$b %= $a`.
Why do you see `$filters = collect($filters)->map()->all();` in Laravel
project code more often than `transform($filters)`? Because developers
also write in JavaScript, which lacks a `transform` method.
Consequently, the `map` logic is more familiar to them, as it behaves
predictably in both languages. And why doesn't JavaScript have a similar
`transform` method? Because it can lead to unpredictable side effects.
For example, if a handler accesses not only the current element but the
entire collection as well, it is completely unclear whether the handler
for the second element will see the first element in its modified state
or its original one. The approach involving an immutable map and
assignment after the entire array has been processed creates more
predictable behavior. It is precisely this immutability of the source
array that allows certain languages to process elements within a map
in parallel or employ other optimizations without the risk of side
effects or race conditions. If I understand correctly, Larry wants the
language to move in precisely this direction.
18.07.2026 3:01, Caleb White пишет:
Hi everyone, thanks for the feedback.
On Friday, July 17th, 2026 at 13:08, Larry Garfield <[email protected]>
wrote:
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
I understand the FP perspective, but PHP isn't an immutable language.
We mutate variables constantly; that's why `+=`, `.=`, and `??=` exist.
The motivation for this RFC came from seeing this pattern and wishing
that such an operator existed.
--
--
Vadim Dvorovenko
