03.02.2026 22:13, Tim Düsterhus:
That said, I agree with the others that I find the proposal a step backwards in terms of readability. Having the `return` at the start of the line is a clear indicator that the function ends there and it is only a “single bit” of information I have to keep in mind while I continue reading until I find the semicolon ending the statement. It is also consistent with how assignments - the other primary use case for pipes - start with the target variable and the equals before the “pipe expression”. I think it would not be wrong to think of `return` as “assigning to the return value”.
Some time ago, I raised dicussion (https://news-web.php.net/php.internals/128141) of using pipes for assignment as well, you also took part in that discussion. Currently, i started with the RFC for `return` because it's simplest, to illustrate main cognitive problem. By the way, returning is something that can not be implemented function like assign_to.
The main idea is that the pipe operator's main drawback is that it changes the usual reading direction. Function composition via + doesn't have this drawback. Maybe if function composition had been implemented earlier, the pipe operator wouldn't have been adopted. Now the pipe operator is part of the language, and I'm just trying to expand its use cases to write more intuitive and native-language-like code.
Look, even simple statements like `return $x |> strlen(...);` may be confusing, if you were not familiar with the pipe operator before, because you do not understand, if you should stop after `return $x` or not. On the other side `$x |> strlen(...) |> return` is more intuitive in this way, even if you see |> for the first time, reading this line you understand, that it has two actions, defined by arrows, and it is some sort of data transfer.
Even though you know `|>` is called a pipe operator, the `return $x |> strlen(...);` expression doesn't show how the data is flowing through the pipes. Something like `return strlen(...) <| $x` would be much more expressive in this sense. I had an idea to bring an RFC for the pipe operator to the left instead of this. But i chose not to invent a new operator, but simply to expand the grammatical possibilities of using an existing one.
