Re: [PHP-DEV] [RFC] Pipe Assignment Operator

Hi

On 2026-07-20 04:11, Larry Garfield wrote:
> 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.

Nothing about `|>` is unique to functional programming or immutability, 
it's just another way of writing a function call. I disagree with trying 
to academically gatekeep functionality that is entirely consistent with 
PHP’s current semantics in an attempt to push PHP into any specific 
paradigm, particularly when it’s a paradigm that does not match how a 
majority of PHP code is written in practice.

With regard to “you shouldn't modify variables in-place”, I'd like to 
note that Rust, a language where variables are immutable by default, 
supports reassigning a variable to be of a different type *in spirit* by 
redeclaring and thus shadowing the previous variable. In some cases this 
is even necessary to satisfy the borrow checker. Of course, PHP doesn’t 
come with the technical consideration of a borrow checker, but 
incrementally refining a value is nevertheless a common pattern - 
something I also do in Rust, even when not technically required - and I 
find that the RFC makes a good example with the “Sequential Processing” 
(https://wiki.php.net/rfc/pipe_assignment_operator#sequential_processing).

> and none of these will make it into 8.6.

This is false: The featured RFC had its last change on July 14th (which 
I consider to be a minor change), and the last major change on July, 
13th. This means it may open voting starting July 27th, ending August 
10th and meeting the soft freeze deadline. Even if we consider the 
change on the 14th to be a major change, it may (barely) meet the 
deadline.

Best regards
Tim Düsterhus