Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127934
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Mon, 07 Jul 2025 10:35:09 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <10c70b6b-6060-4dd2-8169-fa01890632cb@app.fastmail.com>
In-Reply-To: <6a9d4f24-65e4-40ee-bf16-9b1120486d83@app.fastmail.com>
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
 <6a9d4f24-65e4-40ee-bf16-9b1120486d83@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Partial Function Application v2
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jul 4, 2025, at 5:27 PM, Rob Landers wrote:
> On Sat, Jun 28, 2025, at 07:06, Larry Garfield wrote:
>> Hi folks.  Arnaud and I would like to present take-2 at Partial Funct=
ion Application.
>>=20
>> https://wiki.php.net/rfc/partial_function_application_v2
>>=20
>> It is largely similar to the previous PFA proposal from 2021, though =
there are a number of changes.  Most notably:
>>=20
>> * The implementation is simpler, because FCC already did part of the =
work.  This RFC can build on it.
>> * Constructors are not supported.
>> * But optional arguments and named placeholders are supported.
>> * It includes pipe-based optimizations.
>>=20
>> Note: We realize that this is a non-trivial RFC coming late in the cy=
cle.  We are proposing it now because, well, it's ready now.  If the dis=
cussion goes smoothly, we're OK calling a vote on it for 8.5, especially=
 as it would complement pipes so well.  If the discussion runs longer, w=
e're also OK with targeting 8.6 instead.  We'll see how that goes.
>>=20
>> <floor opens for discussion, Larry falls through the trap door>
>>=20
>> --=20
>>   Larry Garfield
>>   larry@garfieldtech.com
>>=20
>
> Hi Larry,
>
> I hope your trip through the trap door is largely uneventful with a=20
> smooth integration into 8.5.
>
> My only question: why does this implementation care if you specify too=20
> many arguments when PHP doesn=E2=80=99t care if you call a function wi=
th too=20
> many arguments?
>
> I think it=E2=80=99s a good thing that it cares, and I think PHP itsel=
f should=20
> care, but should this RFC change that expectation?
>
> =E2=80=94 Rob

Largely because it conflicts with the intent of the closure author, and =
may have unexpected interaction with optional args otherwise.

Eg:

function f($a, $b =3D 0) {}
$f =3D f(?);
$f(1, 2);

Is 2 bound to $b ? If yes this goes against the intent of the PFA creato=
r. But if not this is weird. Therefore it=E2=80=99s better if that=E2=80=
=99s not allowed, as that's the least-weird outcome.

If the closure author wants to allow trailing arguments, they can use th=
e ... placeholder, which would allow for that.  So:

function f($a, $b =3D 0) {}
$f =3D f(?, ...);
$f(1, 2);

It's self-evident that trailing args are allowed, and that it's the auth=
or's intent, so in this case all is well and there's no (unexpected) wei=
rdness.

--Larry Garfield