I hereby open the vote on the Pipe operator RFC:
https://wiki.php.net/rfc/pipe-operator-v3
The vote will run until 26 May.
--
Larry Garfield
larry@garfieldtech.com
Thank you for your work on this.
While I will enjoy this feature if it passes, it irks and saddens me that...
once\again::PHP->has|>added
a.feature.other.languages.only.need.dot.for
That isn't your fault, and any hope of changing that about the language
left the station decades ago.
On Mon, May 12, 2025 at 9:58 PM Larry Garfield larry@garfieldtech.com
wrote:
I hereby open the vote on the Pipe operator RFC:
https://wiki.php.net/rfc/pipe-operator-v3
The vote will run until 26 May.
--
Larry Garfield
larry@garfieldtech.com
I hereby open the vote on the Pipe operator RFC:
https://wiki.php.net/rfc/pipe-operator-v3
The vote will run until 26 May.
Hey, Larry, quick check:
Supporting pass-by-ref parameters in simple cases is quite easy, and
a naive implementation would support it. However, passing a value
from a compound value (an object property or array element) by
reference does not work, and throws an “Argument could not be passed
by reference” error. In practice, it is easier to forbid pass-by-ref
parameters in pipe than to allow them.
Is this a restriction that can be lifted in a future version? I agree
that it's unlikely to be useful, but if the $temp = chain version
supports it, then so too I would expect a pipeline to be able to
handle it.
I hereby open the vote on the Pipe operator RFC:
https://wiki.php.net/rfc/pipe-operator-v3
The vote will run until 26 May.
Hey, Larry, quick check:
Supporting pass-by-ref parameters in simple cases is quite easy, and
a naive implementation would support it. However, passing a value
from a compound value (an object property or array element) by
reference does not work, and throws an “Argument could not be passed
by reference” error. In practice, it is easier to forbid pass-by-ref
parameters in pipe than to allow them.Is this a restriction that can be lifted in a future version? I agree
that it's unlikely to be useful, but if the$temp =chain version
supports it, then so too I would expect a pipeline to be able to
handle it.
Lifting it on simple variables (strings, ints, etc.) is quite simple. It actually took effort (not much) to make those not work, so that could just be undone in like 2 lines. References to compound variables, I don't know how to make work. It might be possible for someone with more engine-fu for me to figure that out, I don't know. But since IMO one shouldn't be using references in a pipe chain anyway, I didn't invest much time in figuring out how to do so.
--Larry Garfield
Hi Larry
I hereby open the vote on the Pipe operator RFC:
It looks like the example under "Rejected Features" is wrong.
// With Elixir style
$foo
|> bar(...)
should be
$foo
|> bar()
Also a nit: The RFC says "There was discussion off-list of
“auto-partialling” functions after a pipe", but this idea was since
discussed on-list as well.
Ilija
Hi Larry
I hereby open the vote on the Pipe operator RFC:
It looks like the example under "Rejected Features" is wrong.
// With Elixir style
$foo
|> bar(...)should be
$foo
|> bar()Also a nit: The RFC says "There was discussion off-list of
“auto-partialling” functions after a pipe", but this idea was since
discussed on-list as well.Ilija
Hm, good catch. Normally you're not supposed to edit an RFC in voting, but as this is a typo fix in a Rejected Features section (ie, it has zero impact on the thing being voted on), I think it's probably OK to fix.
I'll give a day or so for someone to object that it still shouldn't be allowed, and if no one does then I'll make those edits.
--Larry Garfield
I hereby open the vote on the Pipe operator RFC:
It looks like the example under "Rejected Features" is wrong.
// With Elixir style
$foo
|> bar(...)should be
$foo
|> bar()Also a nit: The RFC says "There was discussion off-list of
“auto-partialling” functions after a pipe", but this idea was since
discussed on-list as well.Ilija
Hm, good catch. Normally you're not supposed to edit an RFC in voting,
but as this is a typo fix in a Rejected Features section (ie, it has
zero impact on the thing being voted on), I think it's probably OK to fix.I'll give a day or so for someone to object that it still shouldn't be allowed,
and if no one does then I'll make those edits.--Larry Garfield
I think it's fine to fix typos, misspellings, and grammar mistakes which don't affect what's being voted on.
While you're at it, please also fix the match() example, which should not contain case keywords.
Theodore
I hereby open the vote on the Pipe operator RFC:
It looks like the example under "Rejected Features" is wrong.
// With Elixir style
$foo
|> bar(...)should be
$foo
|> bar()Also a nit: The RFC says "There was discussion off-list of
“auto-partialling” functions after a pipe", but this idea was since
discussed on-list as well.Ilija
Hm, good catch. Normally you're not supposed to edit an RFC in voting,
but as this is a typo fix in a Rejected Features section (ie, it has
zero impact on the thing being voted on), I think it's probably OK to fix.I'll give a day or so for someone to object that it still shouldn't be allowed,
and if no one does then I'll make those edits.--Larry Garfield
I think it's fine to fix typos, misspellings, and grammar mistakes
which don't affect what's being voted on.While you're at it, please also fix the
match()example, which should
not containcasekeywords.Theodore
I have made the above corrections. No substantive changes were made to the RFC.
For verification, here's the diff: https://wiki.php.net/rfc/pipe-operator-v3?do=diff&rev2%5B0%5D=1747101303&rev2%5B1%5D=1747316653&difftype=sidebyside
--Larry Garfield
I hereby open the vote on the Pipe operator RFC:
https://wiki.php.net/rfc/pipe-operator-v3
The vote will run until 26 May.
The vote is now closed. The final tally is 33 Yes to 7 No, or about 82%. The RFC passes.
Thank you everyone for your participation. I'll try to get the PR merged ASAP. Hopefully expect some follow up RFCs (as discussed in future scope) fairly soon.
--Larry Garfield