Hey Caleb,
On 10.07.26 11:45, Caleb White wrote:
Hi internals,
I'd like to open discussion on my (first!) RFC for the pipe assignment operator
(|>=):
https://wiki.php.net/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:
https://github.com/php/php-src/pull/22633
Looking forward to your feedback.
Thanks!
Caleb
Thanks for the RFC! As you already could guess I am in support. Been
running your implementation and didn't run into anything unexpected, nor
was I able to break it in different ways than the current pipe
behaviour. Though, I'd like to add the following.
1) This was feeling nitpicky at first, but it doesn't leave me alone
since I first read your RFC. :) Now, given what Vadim added to the
discussion, I think it is worth bringing it up. Right now we are doing:
```
$someVar = $someVar |> array_filter(...);
```
the RFC allows to omit the noise:
```
$someVar = |> array_filter(...);
```
you see where I am going; now let's remove the white space:
```
$someVar =|> array_filter(...);
```
my point is: why `|>=` and not `=|>`?
I think the latter would be more intuitive: assign the result of piping
to the variable. I know that `|>=` follows the established `foo=`
convention for compound assignments like `??=` or `.=`; which is an
argument in its favour. Still, I think `=|>` better communicates how
this particular operation expands. Especially when considering future
additions like the ones Vadim proposes in future scope.
Because a side effect of having `=|>` would be that the right hand side
of `|>` remains open to extension for potential in-pipe-behaviour
modifying features like the ones Vadim proposes -- without the final
assignment being affected. As in, `=|>` assigns the pipe result, while
`=|>+`, `=|>-`, `=|> .`, `=|>whatever` allow modifying in-pipe
behaviour. This would make sense because perhaps these pipe behaviour
operators will also be allowed for non-shorthand assigned (`|>+`, `|>
-`, `|> .` ) pipes that want the resulting immutable right hand side
Larry made an argument for. Having a clear separation between
assignment, and potential future additions to modify pipe behaviour
makes sense. As in, want to add a modifying operator later? Cool, your
assignment remains in tact `=|>`. You just add a modifying operator
`=|>-` instead of flipping from `|>=` to `|>-=` which would affect final
assignment *and* in-pipe behaviour -- having the modifier out of the
final assignment decision is cleaner.
Also, it is not impossible that what Vadim proposes in future scope
would result in something like `|>=??=` which IMO makes an even stronger
point for strictly separating what is proposed here and potential future
additions of modifying operators: `=|> .. |> ??=`. Because these *are*
different: `... |> ??=` (for in-pipe operations) and `=|> ... |> ??=`
(only for the final assignment). Vadims proposal makes sense on it's
own, but it currently mixes two concerns: in-pipe operations and final
assignment -- which I believe should be separated. Both of your
proposals (especially Vadims future scope) should probably rather
complement each other instead of competing; I think what I am writing
here potentially could make this easier.
One additional soft argument is that text ligatures will show >= as ≥
which will just add to the confusion if modifying operators as Vadim
proposes in future scope would ever be added.
Long story short: `=|>`over `|>=` IMO has a lot of appeal.
Though, I know not having `|>=` would deprive us of the "volcano
operator" naming; sorry for being the party pooper.
2) Holly brought up this example:
```
$foo |>= a(…)
$foo |>= b(…)
$foo |>= c(…)
```
and it seems you talked past each other. Hollys example didn't end lines
with semicolons, while your answer had them. Currently, the
non-semicolon variant:
```
$foo = "hello";
$foo |>= strtoupper(...) // no semicolon
$foo |>= strtolower(...);
var_dump($foo);
```
throws with "Parse error: syntax error, unexpected variable "$foo" in".
In the same way the current
```
$foo = "hello";
$foo |> strtoupper(...) // no semicolon
$foo |> strtolower(...);
var_dump($foo);
```
throws. I just wanted to point this out because apparently it caused
confusion in the discussion. Perhaps worth to clarify the RFC (even
though it's also current pipe behaviour).
3) I recently discovered a bug [1] when pipes are combined with property
hooks. Unsurprisingly, with your addition it is the same. However, since
this shows that pipes are not behaving everywhere identical it would
probably be good to add some tests to confirm the interaction of
assigned pipes with property hooks, readonly etc. -- and maybe also to
clarify it in the RFC.
---
Cheers
Nick
[1] https://github.com/php/php-src/issues/22587
