[Vote] Pipe operator

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:

https://wiki.php.net/rfc/pipe-operator-v3

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