Re: Pipe precedence challenges

On Thursday 21 August 2025 15:53:12 (+02:00), Larry Garfield wrote: > The main problem is not when a pipe is inside a closure, but when a > closure is inside a pipe, which is likely the far more common case. > > ...The annoying extra parens there would also be resolved using PFA > ... (As would using higher-order functions instead...) Thank you for pointing to the PFA RFC. It indeed highlights the very verbosity problem that leads to the current parsing conflict. It's clear that PFA is the ideal, holistic solution to making functions pipe- compatible. Given that PFA is not part of the current release cycle, we are effectively in a transitional state where we have the Pipe operator but not its ideal companion. The mandatory parentheses are a necessary fix for the grammar, but they accentuate the very syntactic noise we aim to reduce. This precedence issue has led me to look back at the history of this feature, and I was fascinated to find Sara Golemon's original 2016 RFC. It's striking that the very first proposal for a pipe operator in PHP included a placeholder syntax ($$) as a core part of the design. This suggests that the challenge of cleanly integrating multi-argument functions into a pipeline was identified from the very beginning. The current situation—where we have the pipe operator but not its intended companion (PFA)—is an intermediate state that the original design sought to avoid. My 'canned pipes' suggestion is an attempt to address this same funda- mental need for a placeholder within the current grammatical constraints. It provides a path to recapture that original vision of clean, readable pipelines today, while we work towards the broader solution of general- purpose PFA in the future. It's a proposal I'm happy with whatever the outcome—however it yields, and whether or not we can capture the return value with or without parentheses. Looking forward to seeing the fix evolve and thanks again for your work on this! Best, hakre