On Sun, Jul 19, 2026, at 12:37 AM, Vadim Dvorovenko wrote:
> 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.
Impressively, I think this explanation stated my position better than I could.
:-) Yes, I am in favor of pushing PHP in a more-functional, mostly-immutable
direction (without going all the way to pathological purity like in Haskell).
A variant of pipe that is intrinsically built on mutable variables goes against
the intent. Yes, PHP is not an inherently immutable language today, but you
can easily use it that way if you're careful and know where the edges are where
you shouldn't.
I think the above description has actually pushed me over into the No category
on this RFC. (Which doesn't mean I'm necessarily in favor of the alternate |>=
proposal. I'm still pondering that one.)
I do agree that some longer-term planning around what alternate pipe forms make
sense is wise, and a conversation I'm open to having. But not for a few weeks,
as we should be focused on 8.6 at the moment, and none of these will make it
into 8.6.
--Larry Garfield
