Proposal. Pipeline assignment operator

On Sun, Jul 20, 2025, at 5:22 AM, Ilija Tovilo wrote:

I am also not a fan of this proposal for much the same reason. First, the mental model it proposes I do not agree with. The model of <variable to assign to> = <arbitrarily complex expression> is fairly universal in PHP and in most languages. It's quite self evident at this point. Furthermore, there are plenty of other "read down and up" use cases beyond pipe. match() and ternaries come to mind as common examples. The behavior of pipes with variables is also very well defined. The left side is any expression (including a variable). The right side is a callable. That callable could be a variable that references a Closure, and often will be. So it's already quite clear what will happen If we were to agree that there was a use case for "reverse assignment" (of which I am not yet convinced), it should be its own stand-alone thing. Just for argument's sake (not actually proposing this): <expression> ==> <variable to assign to> That would then work at the end of a pipe chain, a match statement, a ternary, or whatever else you felt like. Self-contained parts that play well with others are almost always superior to a one-off solution. --Larry Garfield

Sorry, that's my first reply to mailing list discussion, maybe i'm not doing it right. Ilija wrote:

You're providing some fluent-like syntax as example of situation. Foobar example does not show all posible use cases. Compare, two code blocks, they are read differently even same syntax. // no need to replace with pipe operator. // you even will not try to wrap such code to improve readability. Little chance structure will change in future, order of call could not be changed. // no need of left to right assignment in this case. Little chancethat expression will grow more than 2-3 lines. $x = $movies->getMovie()->getCharacters()->getCharacter() // complex structure access, inspired by (inspired by https://www.php.net/manual/en/simplexml.examples-basic.php) $y = collect($strings)->trim()->toUpper()->implode(','); // Fluent chain of calls. this case is what pipe operator for. // you will probably want to wrap this line to improve readability. Order of processing is point of further changes. List can grow, leading to 10-15 lines of piped function calls, if some map calls or other transformations are added. In fluent we even can write foo()->bar()->baz()->assignTo($x) (as it's user-defined method, we can make any logic). With fluent we do not need nor pipe, nor ltr-assignment. But someone thought fluent syntax is not good, as this is not native language operator, but a wrapper pattern, and we have pipe operator now. But we must remember that fluent syntax appeared precisely because the language did not have tools to record the order of calls from left to right and top to bottom. From a programming language perspective, fluent syntax is just a chain of calls. The appearance of such an language element as the pipe operator in the programming language proves that the need for reading the calls from left to the right existed. And this need is dictated precisely by our perception of the code, and not by some technical need. This also proves that we have same need of left-to-right assignment operator, caused by same feature of human perception. My proposal is about need of left to right assignment operator together with left to right function call operator. As idea was inspired by pipe operator rfc, so i chosed operator most looked like pipe. If the pipe symbol distracts from the essence, lets' discuss some other symbol, e.g. --> $x --> $y; $strings   |> 'trim'   |> 'toUpper'   |> implode(',', ...)   --> $y foo() ->bar() ->baz() --> $x;

You're speaking about left-hand side of operator. I'm speaking about case, where variable is in the right side of pipe operator. RFC contains no examples, where there's variable, storing callable. Even without my proposal, this should be clarified in documentation on pipe operator. Expression $x |> $y can mislead.