Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130061
Message-ID: <89a586d3-6eee-45eb-9a2d-cb432589aaae@gmail.com>
Date: Mon, 9 Feb 2026 02:19:39 +0700
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Pipe to return
To: Rob Landers <rob@bottled.codes>, internals@lists.php.net,
 =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
References: <53c17181-caa4-41a3-b4ab-93069e6bb47b@gmail.com>
 <58b0417b-15fb-44cd-aaf1-7d88c291c491@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <58b0417b-15fb-44cd-aaf1-7d88c291c491@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: vadim.dvorovenko@gmail.com (Vadim Dvorovenko)

31.01.2026 20:45, Rob Landers:
> I get I could just ... not do that ... but since this seems to be 
> about cognitive load, I think this would actually add additional 
> cognitive load instead of removing it. Often, you need to find where 
> the function returns; more often than you need to read actual pipes.
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”.


Thanks for these comments. I find them among the most valuable in this 
discussion. They really made me think for a long time and experiment a lot.

To discuss them, I've been going through and trying to come up with 
different code options. Unfortunately, there aren't any successful 
examples yet in the real projects and libraries I work with. If you 
could provide links to repositories where pipe operator is actively 
used, I'd be very grateful. So for now I apologize for the fictitious 
example.

Let's take this complex function

     function process_request($request)
     {
         if ($request instanceof ManageEmployeeRequest) {
             if ($request instanceof CreateEmployeeRequest) {
                 return $request |> logRequest(...) |> 
validateCreateEmployeeRequest(...) |> processCreateEmployee(...) |> 
formatEmployeeDataAsArray(...) |> convertArrayToJsonResponse(...);
             } elseif ($request instanceof UpdateEmployeeRequest) {
                 return $request |> logRequest(...) |> 
validateUpdateEmployeeRequest(...) |> processUpdateEmployee(...) |> 
formatEmployeeDataAsArray(...) |> convertArrayToJsonResponse(...);
             } elseif ($request instanceof DeleteEmployeeRequest) {
                 $request |> logRequest(...) |> 
validateDeleteEmployeeRequest(...) |> processDeleteEmployee(...);
                 return [] |> convertArrayToJsonResponse(...);
             } else {
                 throw new InvalidArgumentException("Unknown client 
request type");
             }
         }
         if ($request instanceof ManageClientRequest) {
             if ($request instanceof CreateClientRequest) {
                 return $request |> validateCreateClientRequest(...) |> 
processCreateClient(...) |> formatClientDataAsArray(...) |> 
convertArrayToJsonResponse(...);
             } elseif ($request instanceof UpdateClientRequest) {
                 return $request |> validateUpdateClientRequest(...) |> 
processUpdateClient(...) |> formatClientDataAsArray(...) |> 
convertArrayToJsonResponse(...);
             } elseif ($request instanceof DeleteClientRequest) {
                 $request |> validateDeleteClientRequest(...) |> 
processDeleteClient(...);
                 return convertArrayToJsonResponse([]);
             } else {
                 throw new InvalidArgumentException("Unknown client 
request type");
             }
         }
         throw new InvalidArgumentException("Unknown request type");
     }

When we read this function, we are actually more interested in the 
structure of conditions and returns than in the actual actions. In this 
case, of course, return at the beginning of the line is indeed more 
readable. Here I completely agree with you.

But in real life we ​​won't use such long lines and the chain will be 
split into several lines. Here I used different code styles in one block 
for clarity.

     function process_request($request)
     {
         if ($request instanceof ManageEmployeeRequest) {
             if ($request instanceof CreateEmployeeRequest) {
                 $request
                     |> logRequest(...)
                     |> validateCreateEmployeeRequest(...)
                     |> processCreateEmployee(...)
                     |> formatEmployeeDataAsArray(...)
                     |> convertArrayToJsonResponse(...)
                     |> return;
             } elseif ($request instanceof UpdateEmployeeRequest) {
                 return
                     $request
                         |> logRequest(...)
                         |> validateUpdateEmployeeRequest(...)
                         |> processUpdateEmployee(...)
                         |> formatEmployeeDataAsArray(...)
                         |> convertArrayToJsonResponse(...);
             } elseif ($request instanceof DeleteEmployeeRequest) {
                 $loggedRequest = logRequest($loggedRequest);
                 $validatedRequest = 
validateDeleteEmployeeRequest($loggedRequest);
                 processDeleteEmployee($validatedRequest);
                 $response = convertArrayToJsonResponse([]);
                 return $response;
             } else {
                 throw new InvalidArgumentException("Unknown client 
request type");
             }
         }
         // ...
     }

In my case, the IDE brightly highlights 'if', 'elseif', and 'return' 
keywords. In this version, I clearly see the return in the first two 
blocks, despite its different placement. The 'return' in the third block 
stands out the least; it blends in with the preceding text because there 
is no indentation. But when I'm composing a letter, I don't have syntax 
highlighting, but the feeling is the same.

The third block looks more like a chain of actions. Of course, it's 
written in imperative style.

The first block also looks like a chain of actions. Vision very quickly 
stops paying attention to `|>`. Moreover, it fits seamlessly into the 
conditions structure. It's clear that this chain of transformations is 
executed under these very conditions. And here it seems to me very 
fortunate that after reading the block to the end, we see return, and we 
don’t need to look up 6 lines above to remember why we performed all 
these actions.

I myself reread the second block several times, trying to understand 
whether it really is more convenient to read. But every time I read the 
chain of actions to the end, I caught myself thinking that I didn’t want 
to go back to check if there was a ‘return’ there. On the contrary, 
during the time I was working with this example, my brain developed a 
rule, and seeing a vertical chain of '|>', I immediately began to look 
at the end of the block to understand whether there is a return at the 
end. It's like looking at the first and last lines of a third block, 
skipping over everything in between. But with `|>`, your eye kind of 
slides down them, and you get to `|> return;` much faster.

I also noticed that when I look at the second block, my vision selects 
the block starting with `$request`. For some reason it crops the 
`return` located to the left and above. I think this is because it is a 
keyword that has ceased to carry meaning for us, and we perceive it as a 
punctuation mark, rather than as carrying meaning.