Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128215
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Thu, 24 Jul 2025 09:04:40 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <779a8062-72d7-405a-b15c-136c8e971f7f@app.fastmail.com>
In-Reply-To: <e2773871f867a6687ed18f2bd681d943@bastelstu.be>
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
 <52dbe5236df460958644677c781513c3@bastelstu.be>
 <dcef6477-d0c6-4cb8-9a5c-acce145062c4@app.fastmail.com>
 <395ee57ca13b16ab09301f9bee6f07b9@bastelstu.be>
 <e2773871f867a6687ed18f2bd681d943@bastelstu.be>
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 Thu, Jul 24, 2025, at 6:52 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-07-24 12:03, schrieb Tim D=C3=BCsterhus:
>> I don't think they should. Specifically the (1) and (3) should not. M=
y=20
>> expectation is that:
>>=20
>>     $f =3D foo(a: ?, b: 2, c: ?);
>>     $f(1, 3); // calls foo(1, 2, 3);
>>=20
>> and
>>=20
>>     $f =3D foo(c: ?, b: 2, a: ?);
>>     $f(1, 3); // calls foo(3, 2, 1);
>>=20
>> The order of the question marks should match the order of the=20
>> parameters in the resulting Closure, which is not necessarily the ord=
er=20
>> of the order parameters of the original function.

That would be inconsistent with how named arguments work anywhere else. =
 With a regular function call, you can list named args in any order you =
feel like and the engine will reorder them for you back to the original =
defined order.  (My IDE keeps yelling at me to put them in order, but th=
at's an IDE problem, not a language problem.)  Having PFA behave differe=
ntly feels needlessly confusing, especially since positional placeholder=
s are supported, too.

$f =3D foo(?, a: ?, b: ?)

It's not obvious to me what should happen there.  Does that implicitly m=
ean $c is now the first argument?  That's not at all apparent from the s=
yntax.

Similarly, in a longer example:=20

foo ($a, $b, $c, $d, $e, $f);

$f =3D foo(?, 3, b: ?, e: ?, ...);

That already takes a moment of thought to know what's going on, despite =
being legal.  (A value is provided for $c, but nothing else.)  Having th=
at also change the order to... I think it would be f($a, $b, $e, $d, $f)=
 ?  Just raises the effort to grok it even further.

The only value to breaking existing convention and reordering parameters=
 I can see would be:

> To add to that: By respecting the order of question marks as written, =
it=20
> would also make PFA easier to understand and also more powerful. After=20
> sending the email earlier, I came across this doctrine/collections PR,=20
> while reviewing some dependency upgrades:=20
> https://github.com/doctrine/collections/pull/424
>
> When migrating the `findFirst()` method from a custom foreach loop to=20
> `array_find()`, they couldn't pass along the given callable directly,=20
> since Doctrine opted for a different parameter order. Thus they needed=20
> an intermediate Closure to swap the arguments. If the argument names f=
or=20
> the function are known (which they are not in the Doctrine example, as=20
> it's an arbitrary Closure that is given), this would allow to swap=20
> arguments as necessary:
>
>      function cb($key, $val) { =E2=80=A6 }
>
>      array_find($array, cb(val: ?, key: ?)); // array_find expects=20
> $value, $key.


Which is valid, but on balance I think it's OK for that case to still be=
 a manual short-closure in exchange for less confusing behavior of PFA. =
 In practice, I expect most PFA uses to be creating unary function anywa=
y, followed by thunks, so it won't greatly matter.

Does anyone else agree/disagree?

--Larry Garfield