Hi
On 2026-07-10 06:45, Caleb White wrote:
I'd like to open discussion on my (first!) RFC for the pipe assignment operator (|>=):
PHP: rfc:pipe_assignment_operator
I've given the RFC a read now and have the following comments:
1.
Conceptionally I like the idea of having an “in-place modification operator” for function calls and the semantics of the operator seem to be consistent with the existing “modify-assign” operators we have, particularly also with regard to operand order. Nice idea!
2.
I appreciate how detailed the RFC describes that the feature will just “work as expected” (e.g. with regard to variables targets or callable styles), this is good to avoid any ambiguity.
3.
The only thing I'm missing for the semantics is an explicit explanation of the operator precedence and associativity (it has the same precedence and associativity as any other assignment operator; but this needs to be in the RFC). And please also include explicit examples along the lines of:
If you write `$foo |>= bar(...) |> baz(...)` it will be interpreted as if you have written `$foo = (($foo |> bar(...)) |> baz(...))` with the very explicit redundant parentheses.
Please also include some additional more complex examples, e.g. `$foo |>= $bar |>= …`, `$foo += $bar |>= …` and similar to make sure there is no ambiguity for possible use cases that users might have.
4.
For the examples, I'd like to note that some of the “before” examples are needlessly complex and might not fairly represent the old code. Specifically:
$input = $input |> trim(...) |> strtolower(...);
$this->currentOrder->lineItems = $this->currentOrder->lineItems
|> array_unique(...)
|> array_values(...)
|> array_reverse(...);
could already be:
$input = trim($input) |> strtolower(...);
$this->currentOrder->lineItems = array_unique($this->currentOrder->lineItems)
|> array_values(...)
|> array_reverse(...);
Best regards
Tim Düsterhus
On Monday, July 13th, 2026 at 12:23, Tim Düsterhus <tim@bastelstu.be> wrote:
1.
Conceptionally I like the idea of having an “in-place modification
operator” for function calls and the semantics of the operator seem to
be consistent with the existing “modify-assign” operators we have,
particularly also with regard to operand order. Nice idea!
Thanks! I'm glad others think so as well :).
2.
I appreciate how detailed the RFC describes that the feature will just
“work as expected” (e.g. with regard to variables targets or callable
styles), this is good to avoid any ambiguity.
Thanks again, trying to make it as clear as possible.
3.
The only thing I'm missing for the semantics is an explicit explanation
of the operator precedence and associativity (it has the same precedence
and associativity as any other assignment operator; but this needs to be
in the RFC). And please also include explicit examples along the lines
of:
If you write `$foo |>= bar(...) |> baz(...)` it will be interpreted as
if you have written `$foo = (($foo |> bar(...)) |> baz(...))` with the
very explicit redundant parentheses.
Please also include some additional more complex examples, e.g. `$foo
|>= $bar |>= …`, `$foo += $bar |>= …` and similar to make sure there is
no ambiguity for possible use cases that users might have.
I've added a section in the RFC for this and included more complex examples.
4.
For the examples, I'd like to note that some of the “before” examples
are needlessly complex and might not fairly represent the old code.
Specifically:
$input = $input |> trim(...) |> strtolower(...);
$this->currentOrder->lineItems = $this->currentOrder->lineItems
|> array_unique(...)
|> array_values(...)
|> array_reverse(...);
could already be:
$input = trim($input) |> strtolower(...);
$this->currentOrder->lineItems =
array_unique($this->currentOrder->lineItems)
|> array_values(...)
|> array_reverse(...);
I've cleaned up the examples to make them more representative of
existing code.
Best,
Caleb
Hi
On 2026-07-13 21:02, Caleb White wrote:
The only thing I'm missing for the semantics is an explicit explanation
of the operator precedence and associativity (it has the same precedence
and associativity as any other assignment operator; but this needs to be
in the RFC). And please also include explicit examples along the lines
of:
If you write `$foo |>= bar(...) |> baz(...)` it will be interpreted as
if you have written `$foo = (($foo |> bar(...)) |> baz(...))` with the
very explicit redundant parentheses.
Please also include some additional more complex examples, e.g. `$foo
|>= $bar |>= …`, `$foo += $bar |>= …` and similar to make sure there is
no ambiguity for possible use cases that users might have.
I've added a section in the RFC for this and included more complex examples.
Thank you. One note regarding “the lowest precedence level, right-associative”. This is not quite correct. While the assignment operators have fairly low precedence, they are not the lowest. As an example, the infamous `$foo = bar() or die()` pattern relies on `or` having a lower precedence than assignment. This should be corrected.
The `$result = ($x |>= double(...)) |> triple(...);` example also doesn't showcase precedence, because of the explicit parentheses.
------
Looking at the RFC examples again, I was reminded of this RFC: PHP: rfc:implicit_move_optimisation, which concerns itself with optimizing the `$foo = func($foo);` case. Perhaps it makes sense to list this in the references section, because with `|>=` this “in-place” reassignment would become an official pattern.
Best regards
Tim Düsterhus
On Tuesday, July 14th, 2026 at 03:22, Tim Düsterhus <tim@bastelstu.be> wrote:
Thank you. One note regarding “the lowest precedence level,
right-associative”. This is not quite correct. While the assignment
operators have fairly low precedence, they are not the lowest. As an
example, the infamous `$foo = bar() or die()` pattern relies on `or`
having a lower precedence than assignment. This should be corrected.
The `$result = ($x |>= double(...)) |> triple(...);` example also
doesn't showcase precedence, because of the explicit parentheses.
Ah, yes. I meant among the symbolic operators but you are correct and I've
updated to make this more clear. I removed the explicit parentheses from the
example.
Looking at the RFC examples again, I was reminded of this RFC:
PHP: rfc:implicit_move_optimisation, which concerns
itself with optimizing the `$foo = func($foo);` case. Perhaps it makes
sense to list this in the references section, because with `|>=` this
“in-place” reassignment would become an official pattern.
I've added this to the references and discussed it in the Future Scope
section.
Best,
Caleb
Hi
On 7/14/26 13:37, Caleb White wrote:
On Tuesday, July 14th, 2026 at 03:22, Tim Düsterhus <tim@bastelstu.be> wrote:
Thank you. One note regarding “the lowest precedence level,
right-associative”. This is not quite correct. While the assignment
operators have fairly low precedence, they are not the lowest. As an
example, the infamous `$foo = bar() or die()` pattern relies on `or`
having a lower precedence than assignment. This should be corrected.
The `$result = ($x |>= double(...)) |> triple(...);` example also
doesn't showcase precedence, because of the explicit parentheses.
Ah, yes. I meant among the symbolic operators but you are correct and I've
updated to make this more clear. I removed the explicit parentheses from the
example.
Thank you, the precedence section LGTM now. And overall I don't have any further comments regarding the contents of the RFC.
Best regards
Tim Düsterhus