Re: [PHP-DEV] [RFC] Pipe to return

Hi

Am 2026-01-31 06:52, schrieb Vadim Dvorovenko:

Introducing Pipe to return RFC

PHP: rfc:pipe_to_return

In short, RFC proposes piping expression result to `return` to be used together with pipe operator to reduce cognitive load

Thank you for your RFC. I appreciate how well-written it is and how carefully you followed the suggested template.

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”.

While it is true that no one is forced to use the new syntax, I will inevitably come across it in libraries that decide to use it, thus I will be forced to know that it is a thing and to understand what it does. And of course all IDEs and static analyzers will need to learn about it as well.

For these reasons, I don't believe it meets the cost-benefit ratio.

Best regards
Tim Düsterhus

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 (php.internals: Proposal. Pipeline assignment operator) 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.

03.02.2026 22:13, Tim Düsterhus:

While it is true that no one is forced to use the new syntax, I will inevitably come across it in libraries that decide to use it, thus I will be forced to know that it is a thing and to understand what it does. And of course all IDEs and static analyzers will need to learn about it as well.

Of course, I can't cover all areas, especially proprietary IDEs. However, I planned to prepare corresponding changes for the following tools: nikic/PHP-Parser, psalm, phpstan, php-cs-fixer. If this could affect the vote, I can prepare changes to the this projects before the vote.