Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123041
Content-Type: multipart/alternative;
 boundary="------------f0Ug0uvRwN48TKd55jomaspv"
Message-ID: <e01096ff-dd8d-46b7-bad3-a71a24bfda6e@uzy.me>
Date: Mon, 8 Apr 2024 14:00:57 +0200
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] RFC idea: using the void type to control maximum arity
 of user-defined functions
To: internals@lists.php.net
References: <6299b649-c19b-4172-9632-2ef0a55d256d@uzy.me>
 <CA+pig-JBkZip5bEM0gSwcwNRO9NDKuRO2vu=iHnx2diBTv9Bng@mail.gmail.com>
 <7B32AF65-CA40-40F5-BA59-CB5180EC4D7F@gmail.com>
 <8f71d807-78e6-49f6-acc7-b1fc09d815ba@uzy.me>
 <989e3e13-48ee-4970-8485-f79bb70ad37c@bastelstu.be>
 <CAPyj-LCGNh6HdnLiEcS2kTSzC+_xhdypxVSf7DqbBpR6zmuU0Q@mail.gmail.com>
 <e43b5ff5-2d0c-4310-9f38-039d5b54a825@app.fastmail.com>
Content-Language: fr
In-Reply-To: <e43b5ff5-2d0c-4310-9f38-039d5b54a825@app.fastmail.com>
From: r@uzy.me (Pablo Rauzy)

This is a multi-part message in MIME format.
--------------f0Ug0uvRwN48TKd55jomaspv
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hello all,

Le 05/04/2024 à 15:53, Larry Garfield a écrit :
> On Thu, Apr 4, 2024, at 9:27 PM, Ilija Tovilo wrote:
>> On Thu, Apr 4, 2024 at 5:58 PM Tim Düsterhus<tim@bastelstu.be>  wrote:
>>> On 4/4/24 16:36, Pablo Rauzy wrote:
>>>> I strongly agree in theory, but this could break existing code, and
>>>> moreover such a proposal was already rejected:
>>>> https://wiki.php.net/rfc/strict_argcount
>>> The RFC is 9 years old by now. My gut feeling is be that using an actual
>>> variadic parameter for functions that are variadic is what people do,
>>> because it makes the function signature much clearer. Actually variadic
>>> parameters are available since PHP 5.6, which at the time of the
>>> previous RFC was the newest version. Since then we had two major
>>> releases, one of which (7.x) is already out of support.
>>>
>>> I think it would be reasonable to consider deprecating passing extra
>>> arguments to a non-variadic function.
>> IIRC one of the bigger downsides of this change are closure calls that
>> may provide arguments that the callee does not care about.
>>
>> https://3v4l.org/0QdoS
>>
>> ```
>> function filter($array, callable $c) {
>>      $result = [];
>>      foreach ($array as $key => $value) {
>>          if ($c($value, $key)) {
>>              $result[$key] = $value;
>>          }
>>      }
>>      return $result;
>> }
>>
>> var_dump(filter(['foo', '', 'bar'], function ($value) {
>>      return strlen($value);
>> }));
>>
>> // Internal functions already throw on superfluous args
>> var_dump(filter(['foo', '', 'bar'], 'strlen'));
>> ```
>>
>> The user may currently choose to omit the $key parameter of the
>> closure, as it is never used. In the future, this would throw. We may
>> decide to create an exemption for such calls, but I'm not sure
>> replacing one inconsistency with another is a good choice.
>>
>> Ilija
> This is unfortunately not reliable today, because of the difference between how internal functions and user-defined ones are handled.  The code above will fatal if you use a callable that is defined in stdlib rather than in user-space.  I have been bitten by this many times, and is why I ended up with double the functions in my FP library:
>
> cf:https://github.com/Crell/fp/blob/master/src/array.php#L34
>
> It's also been argued to me rather effectively that ignoring trailing values and optional arguments creates a whole bunch of exciting landmines, as you may pass an "extra" parameter to a function expecting it to be ignored, but it's actually part of the optional arguments so gets used.  The standard example here is intval($value, $base=10).  Basically no one uses the $base parameter, and most people forget it exists, but if you allow an optional value to get passed to that, especially if in weak typing mode, you could get hilariously wrong results.  (For sufficiently buggy definitions of hilarious.)
>
> The behavior difference between internal and user-defined functions is the root issue.  One way or another it should be addressed, because the current behavior is a landmine I have stepped on many times.
>
> --Larry Garfield

So what should be done to move forward with this?

Should the old RFC on strict argument count be revived?

Or should a new RFC proposal be written? If so, should it contain an 
approval voting (where voters can select any number of candidates), 
prior to the RFC proposal vote itself, to decide if the change should 
be: strict argument count, using the void keyword to explicitely stop 
the argument list, or using a #[Nonvariadic] attribute?

Best regards,

-- 
Pablo

--------------f0Ug0uvRwN48TKd55jomaspv
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>
    <p>Hello all,<br>
    </p>
    <div class="moz-cite-prefix">Le 05/04/2024 à 15:53, Larry Garfield a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:e43b5ff5-2d0c-4310-9f38-039d5b54a825@app.fastmail.com">
      <pre class="moz-quote-pre" wrap="">On Thu, Apr 4, 2024, at 9:27 PM, Ilija Tovilo wrote:
</pre>
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">On Thu, Apr 4, 2024 at 5:58 PM Tim Düsterhus <a class="moz-txt-link-rfc2396E" href="mailto:tim@bastelstu.be">&lt;tim@bastelstu.be&gt;</a> wrote:
</pre>
        <blockquote type="cite">
          <pre class="moz-quote-pre" wrap="">On 4/4/24 16:36, Pablo Rauzy wrote:
</pre>
          <blockquote type="cite">
            <pre class="moz-quote-pre" wrap="">I strongly agree in theory, but this could break existing code, and
moreover such a proposal was already rejected:
<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/strict_argcount">https://wiki.php.net/rfc/strict_argcount</a>
</pre>
          </blockquote>
          <pre class="moz-quote-pre" wrap="">
The RFC is 9 years old by now. My gut feeling is be that using an actual
variadic parameter for functions that are variadic is what people do,
because it makes the function signature much clearer. Actually variadic
parameters are available since PHP 5.6, which at the time of the
previous RFC was the newest version. Since then we had two major
releases, one of which (7.x) is already out of support.

I think it would be reasonable to consider deprecating passing extra
arguments to a non-variadic function.
</pre>
        </blockquote>
        <pre class="moz-quote-pre" wrap="">
IIRC one of the bigger downsides of this change are closure calls that
may provide arguments that the callee does not care about.

<a class="moz-txt-link-freetext" href="https://3v4l.org/0QdoS">https://3v4l.org/0QdoS</a>

```
function filter($array, callable $c) {
    $result = [];
    foreach ($array as $key =&gt; $value) {
        if ($c($value, $key)) {
            $result[$key] = $value;
        }
    }
    return $result;
}

var_dump(filter(['foo', '', 'bar'], function ($value) {
    return strlen($value);
}));

// Internal functions already throw on superfluous args
var_dump(filter(['foo', '', 'bar'], 'strlen'));
```

The user may currently choose to omit the $key parameter of the
closure, as it is never used. In the future, this would throw. We may
decide to create an exemption for such calls, but I'm not sure
replacing one inconsistency with another is a good choice.

Ilija
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
This is unfortunately not reliable today, because of the difference between how internal functions and user-defined ones are handled.  The code above will fatal if you use a callable that is defined in stdlib rather than in user-space.  I have been bitten by this many times, and is why I ended up with double the functions in my FP library:

cf: <a class="moz-txt-link-freetext" href="https://github.com/Crell/fp/blob/master/src/array.php#L34">https://github.com/Crell/fp/blob/master/src/array.php#L34</a>

It's also been argued to me rather effectively that ignoring trailing values and optional arguments creates a whole bunch of exciting landmines, as you may pass an "extra" parameter to a function expecting it to be ignored, but it's actually part of the optional arguments so gets used.  The standard example here is intval($value, $base=10).  Basically no one uses the $base parameter, and most people forget it exists, but if you allow an optional value to get passed to that, especially if in weak typing mode, you could get hilariously wrong results.  (For sufficiently buggy definitions of hilarious.)

The behavior difference between internal and user-defined functions is the root issue.  One way or another it should be addressed, because the current behavior is a landmine I have stepped on many times.

--Larry Garfield
</pre>
    </blockquote>
    <p>So what should be done to move forward with this?</p>
    <p>Should the old RFC on strict argument count be revived?</p>
    <p>Or should a new RFC proposal be written? If so, should it contain
      an approval voting (where voters can select any number of
      candidates), prior to the RFC proposal vote itself, to decide if
      the change should be: strict argument count, using the void
      keyword to explicitely stop the argument list, or using a
      #[Nonvariadic] attribute?<br>
    </p>
    <p>Best regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Pablo</pre>
  </body>
</html>

--------------f0Ug0uvRwN48TKd55jomaspv--