On Saturday, July 19th, 2026 at 04:20, Vadim Dvorovenko
<[email protected]> 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
