Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129970
Content-Type: multipart/alternative;
 boundary="------------jKiqhm5wPtHUmgfUBAu3aOkg"
Message-ID: <bdea5946-9ec8-4ae3-b99b-581aad2e19f7@gmail.com>
Date: Sun, 1 Feb 2026 13:17:48 +0700
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Pipe to return
To: Jordi Kroon <jordikroon@me.com>, internals@lists.php.net
References: <53c17181-caa4-41a3-b4ab-93069e6bb47b@gmail.com>
 <019b55a4-8d06-4d88-801e-c3c2de597f1c@Spark>
Content-Language: ru
In-Reply-To: <019b55a4-8d06-4d88-801e-c3c2de597f1c@Spark>
From: vadim.dvorovenko@gmail.com (Vadim Dvorovenko)

This is a multi-part message in MIME format.
--------------jKiqhm5wPtHUmgfUBAu3aOkg
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Jordi Kroon:
> I like the general direction and I am not fully against the idea. That 
> said, I am hesitant to introduce another way to express the same 
> thing, especially when it affects readability.

When we are speaking about pipe operator, it all looks as trying to 
introduce another way to express the same thing, and it affects readability.

As for me,

   $temp = "Hello World";
   $temp = htmlentities($temp);
   $temp = str_split($temp);
   $temp = array_map(strtoupper(...), $temp);
   return $temp;

and

   return array_map(strtoupper(...), str_split(htmlentities("Hello 
World")));

were quite effective ways of expressing value transformation flow. But 
that RFC was adopted. My RFC is an attempt to quickly eliminate the 
cognitive side effects arisen by adding the pipe operator to the language.

The addition of the pipe operator didn't immediately force all language 
users to use it. But it did give them the option. Which method 
of expression of same thing sould be used in different cases, most 
likely will be described later in the coding standards of specific 
projects. Likewise, the method proposed here will not be mandatory for 
use, but there may be cases where it will be chosen for greater readability.

> More importantly, I do not think the responsibility for returning 
> should live inside the pipe. Returning is control flow, while the 
> pipe’s core purpose is transforming data. With this change, the pipe 
> no longer clearly communicates “transform this value,” but can instead 
> become responsible for ending execution. I would rather see the pipe 
> produce a result, and keep the return outside the pipe so the intent 
> stays explicit.
>
> Also, while the example below obviously would not work, it highlights 
> the potential ambiguity this introduces. In a long pipeline, it 
> becomes less clear where returning happens and what role the pipe is 
> playing.
>
> function giveMeFourtyTwo() {
>      return 42
>          |> return;
> }
> Also if you put this into the short `fn` syntax. It will break for the 
> same reasons as above.
>
> fn () => 'hello world'
>          |> strlen(...)
>          |> return;

Our language is now very flexible. But such flexibility would be 
impossible if everithing was strictly divided into categories. Take the 
`throw`, for example. It's obviously intended for flow control. However, 
it can be used anywhere, like in following example.

   return 42 |> fn($val) => throw new RuntimeException($val);
   // or
   throw throw throw new Exception();

Although such a statements contains ambiguity between return and throw, 
or between multiple throws, we don't criticize the language for this 
possibility. In such cases, we say the author of the code has chosen an 
unfortunate style of expression.

My proposal, on the contrary, does not allow using two types of return 
in one expression or using return inside an arrow function. In this 
sense, my proposal is quite strict.
You can use either way of expression, but not both at the same time.

Thus, ambiguity is generated not by the programming language itself and 
its capabilities, but by those who express their thoughts in it. We 
should not limit the expressive instruments of a language simply out of 
fear that they will be misused.


--

Vadim Dvorovenko

--------------jKiqhm5wPtHUmgfUBAu3aOkg
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-text-html" lang="x-unicode">
      <div class="moz-cite-prefix">Jordi Kroon:<br>
      </div>
      <blockquote type="cite"
        cite="mid:019b55a4-8d06-4d88-801e-c3c2de597f1c@Spark">
        <div name="messageBodySection">
          <div dir="auto">I like the general direction and I am not
            fully against the idea. That said, I am hesitant to
            introduce another way to express the same thing, especially
            when it affects readability.</div>
        </div>
      </blockquote>
      <p>When we are speaking about pipe operator, it all looks as
        trying to introduce another way to express the same thing, and
        it affects readability.<br>
        <br>
        As for me,</p>
      <font face="monospace">  $temp = "Hello World";<br>
          $temp = htmlentities($temp);<br>
          $temp = str_split($temp);<br>
          $temp = array_map(strtoupper(...), $temp);<br>
          return $temp;</font>
      <p>and </p>
      <p><font face="monospace">  return array_map(strtoupper(...),
          str_split(htmlentities("Hello World")));</font></p>
      <p>were quite effective ways of expressing value transformation
        flow. But that RFC was adopted. My RFC is an attempt to quickly
        eliminate the cognitive side effects arisen by adding the pipe
        operator to the language.</p>
      <p>The addition of the pipe operator didn't immediately force all
        language users to use it. But it did give them the option.
        Which method of expression of same thing sould be used in
        different cases, most likely will be described later in the
        coding standards of specific projects. Likewise, the method
        proposed here will not be mandatory for use, but there may be
        cases where it will be chosen for greater readability.</p>
      <blockquote type="cite"
        cite="mid:019b55a4-8d06-4d88-801e-c3c2de597f1c@Spark">
        <div name="messageBodySection">
          <div dir="auto">
            <div dir="auto">More importantly, I do not think the
              responsibility for returning should live inside the pipe.
              Returning is control flow, while the pipe’s core purpose
              is transforming data. With this change, the pipe no longer
              clearly communicates “transform this value,” but can
              instead become responsible for ending execution. I would
              rather see the pipe produce a result, and keep the return
              outside the pipe so the intent stays explicit.<br>
              <br>
              Also, while the example below obviously would not work, it
              highlights the potential ambiguity this introduces. In a
              long pipeline, it becomes less clear where returning
              happens and what role the pipe is playing.<br>
              <br>
            </div>
            <pre>function giveMeFourtyTwo() {
    return 42  
        |&gt; return;
}</pre>
          </div>
        </div>
      </blockquote>
      <blockquote type="cite"
        cite="mid:019b55a4-8d06-4d88-801e-c3c2de597f1c@Spark">
        <div name="messageBodySection">
          <div dir="auto">Also if you put this into the short `fn`
            syntax. It will break for the same reasons as above.<br>
            <br>
          </div>
          <pre>fn () =&gt; 'hello world'  
        |&gt; strlen(...)  
        |&gt; return;</pre>
        </div>
      </blockquote>
    </div>
    <p>Our language is now very flexible. But such flexibility would be
      impossible if everithing was strictly divided into
      categories. Take the `throw`, for example. It's obviously intended
      for flow control. However, it can be used anywhere, like in
      following example.</p>
    <pre>  return 42 |&gt; fn($val) =&gt; throw new RuntimeException($val);
  // or
  throw throw throw new Exception();</pre>
    <p>Although such a statements contains ambiguity between return and
      throw, or between multiple throws, we don't criticize the language
      for this possibility. In such cases, we say the author of the code
      has chosen an unfortunate style of expression. </p>
    <p>My proposal, on the contrary, does not allow using two types of
      return in one expression or using return inside an arrow function.
      In this sense, my proposal is quite strict. <br>
      You can use either way of expression, but not both at the same
      time.</p>
    <p><span class="Y2IQFc" lang="en">Thus, ambiguity is generated not
        by the programming language itself and its capabilities, but by
        those who express their thoughts in it. We should not limit the
        expressive instruments of a language simply out of fear that
        they will be misused.</span></p>
    <p></p>
    <p><br>
    </p>
    <p>--</p>
    <p>Vadim Dvorovenko</p>
  </body>
</html>

--------------jKiqhm5wPtHUmgfUBAu3aOkg--