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

Reply via email to