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 `yield`s,
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
