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
