Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122969
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-333-gbfea15422e-fm-20240327.001-gbfea1542
Precedence: bulk
MIME-Version: 1.0
Message-ID: <e43b5ff5-2d0c-4310-9f38-039d5b54a825@app.fastmail.com>
In-Reply-To: 
 <CAPyj-LCGNh6HdnLiEcS2kTSzC+_xhdypxVSf7DqbBpR6zmuU0Q@mail.gmail.com>
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>
Date: Fri, 05 Apr 2024 13:53:56 +0000
To: "php internals" <internals@lists.php.net>
Subject: Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of
 user-defined functions
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Apr 4, 2024, at 9:27 PM, Ilija Tovilo wrote:
> On Thu, Apr 4, 2024 at 5:58=E2=80=AFPM Tim D=C3=BCsterhus <tim@bastels=
tu.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 act=
ual
>> variadic parameter for functions that are variadic is what people do,
>> because it makes the function signature much clearer. Actually variad=
ic
>> 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 =3D [];
>     foreach ($array as $key =3D> $value) {
>         if ($c($value, $key)) {
>             $result[$key] =3D $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 betw=
een 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 va=
lues and optional arguments creates a whole bunch of exciting landmines,=
 as you may pass an "extra" parameter to a function expecting it to be i=
gnored, but it's actually part of the optional arguments so gets used.  =
The standard example here is intval($value, $base=3D10).  Basically no o=
ne uses the $base parameter, and most people forget it exists, but if yo=
u allow an optional value to get passed to that, especially if in weak t=
yping mode, you could get hilariously wrong results.  (For sufficiently =
buggy definitions of hilarious.)

The behavior difference between internal and user-defined functions is t=
he root issue.  One way or another it should be addressed, because the c=
urrent behavior is a landmine I have stepped on many times.

--Larry Garfield