Re: [PHP-DEV] [RFC] Pipe Assignment Operator

Mailing Lists php.internals
1

Hello, Caleb.

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, php.internals: Proposal. Pipeline assignment operator . RFC draft is here php-rfc/ltr-assignment.md at main · vadimonus/php-rfc · GitHub.

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: PHP: rfc:pipe_to_return. You can see another drafts in github.

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.

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.

10.07.2026 11:45, Caleb White пишет:

Hi internals,

I'd like to open discussion on my (first!) RFC for the pipe assignment operator (|>=):
PHP: rfc:pipe_assignment_operator

It adds a compound assignment form of the pipe operator, so that
$x |>= callable is shorthand for $x = $x |> callable, with
support for chaining. Implementation with tests is at:
feat: add pipe assignment operator (`|>=`) by calebdw · Pull Request #22633 · php/php-src · GitHub

Looking forward to your feedback.

Thanks!
Caleb

--
--
Vadim Dvorovenko

2

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,
php.internals: Proposal. Pipeline assignment operator . RFC draft is here
php-rfc/ltr-assignment.md at main · vadimonus/php-rfc · GitHub.

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:
PHP: 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

3

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,
php.internals: Proposal. Pipeline assignment operator . RFC draft is here
php-rfc/ltr-assignment.md at main · vadimonus/php-rfc · GitHub.

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:
PHP: 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

4

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

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.

Vadim Dvorovenko

I see that you formally published your RFC yesterday---I'll link to it in my references.

Best,
Caleb