Re: [RFC] Pipe Assignment Operator

Yes, I have carefully studied the RFCs and understand that they deal with completely different syntax and use cases. However, both proposals advocate for adding and using the |>= operator. Attempting to use it for both scenarios would result in a grammar conflict (the case `$x |>= $y` must be interpreted unambiguously). Therefore, it is appropriate to point out that this is not the only RFC proposing the |>= combination. 19.07.2026 11:54, Caleb White пишет:

On Saturday, July 19th, 2026 at 04:20, Vadim Dvorovenko <vadim.dvorovenko@gmail.com> wrote:

Firtly, i'd like to point out that you aren't the first person to come up with the idea of combining assignment and pipeline operators, and inroduce |>= operator Take a look at discussion, https://news-web.php.net/php.internals/128141 . RFC draft is here https://github.com/vadimonus/php-rfc/blob/main/ltr-assignment.md. I haven't submitted these drafts as an RFC yet because I haven't received enough positive feedback on the first RFC in the chain: https://wiki.php.net/rfc/pipe_to_return. You can see another drafts in github.

Hi Vadim, Thanks for the pointer, interesting to see that the idea of combining assignment with the pipe operator has come up before. Great minds! I did take a look at your pipe-to-return RFC and the LTR assignment draft. These are fundamentally different proposals from what this RFC does, though. Your |>= reverses assignment direction entirely (expr |>= $var means $var = expr), whereas mine is a compound assignment in the traditional sense ($var |>= callable means $var = $var |> callable), the same pattern as +=, .=, and ??=.

The main idea, is that pipe operator reverses traditional funcation call reading order, so we need some more operators with same order to use together to reduce cognitive load. Your variant of this operator makes traditional rigth to left action, like other action. But |> arrow visually defines opposite direction. This may lead to incorrect perception, increase cognitive load and lead to mistakes.

The scope is quite different. Your drafts introduce an entirely new assignment direction for PHP along with a full family of LTR compound operators (|> +=, |> -=, |> .=, etc.). That's a significantly larger surface area change. I'd gently push back on the premise that $result = expr |> f(...) |> g(...) "reverses traditional function call reading order". Pipes don't reverse reading order, they fix it; nested calls read inside-out (g(f(expr))), and pipes linearize that left-to-right. Assignment on the left is just how every C-family language works; nobody reads $result = 1 + 2 and feels a directional conflict. Every language with pipes (F#, Elixir, OCaml, Hack) keeps var = expr |> ... and none of them have introduced LTR assignment to complement it. Even if those proposals were accepted, I think most PHP developers would still reach for $var = expr out of habit and familiarity. So |>= as a compound assignment operator would still have independent value; it makes the very common $x = transform($x) pattern cleaner regardless of whether LTR assignment exists.

I think, all extensions of pipe operator should be ducsussed together to intorduce non conflicting group of operators. Please add to your RFC links to other discussions and theese RFC drafts.

I don't think it makes sense to bundle these together or gate one on the other. They solve different problems and can be evaluated on their own merits. As for adding links to your drafts in my RFC, I'd prefer to keep it focused on its own proposal. You're of course welcome to cross-reference my RFC from your drafts if you'd like. Best, Caleb -- -- Vadim Dvorovenko