Re: [PHP-DEV] [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 <[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
>
-- 
--
Vadim Dvorovenko