Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129043
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sat, 01 Nov 2025 12:54:12 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <e401f4d1-0703-4b62-8ffe-85573a0f64e2@app.fastmail.com>
In-Reply-To: <5db2eea879a3bb5d9788a580f9588276@bastelstu.be>
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
 <13830641-0fb9-4de9-94ed-8873045ef820@app.fastmail.com>
 <a2439dc9-dbb3-4f5f-84f2-b33f988925ea@app.fastmail.com>
 <5db2eea879a3bb5d9788a580f9588276@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 Fri, Oct 31, 2025, at 4:22 AM, Tim D=C3=BCsterhus wrote:
> Hi
>
> Am 2025-10-30 19:44, schrieb Larry Garfield:
>> The one outstanding question is whether we allow reordering using nam=
ed=20
>> arguments or preserve the underlying order.  Arnaud says either one i=
s=20
>> doable.  So far, only 2 people have commented on it (favoring=20
>> reordering).  We still want feedback from more people to see if there=20
>> really is a consensus one way or another.  (2 people is too small a=20
>> sample size to draw any conclusions.)
>
> It appears there is a larger (and unanimous) agreement. This should be=20
> adjusted in the RFC then. Other than that, I've read through the RFC=20
> once more and have the following comments:

Mm, yeah, it would appear I have been outvoted. :-)  So be it.  The RFC =
has been updated to include reordering, and Arnaud will update the imple=
mentation shortly.

I expect this to be the last major change, so we'll likely call the vote=
 in a little over 2 weeks, baring any additional feedback.

> 1. In the //// Regular functions //// examples:
>
> I believe the `static` is missing from every example. Given that the=20
> examples in the Overview at the start already have it, this might be a=20
> mistake?

Artifact of how many times this RFC has been edited. :-)  I think I got =
them all now.

> 2. // Placeholders may be named, too.  Their order doesn't matter.
>
> This example will likely change given the reordering decision, but I'd=20
> like to note a typo: The 's' and 'i' parameters in the PFAs are missin=
g=20
> their number.

I ended up removing this example and replacing it with another anyway.

> 3. (four(c: ?, d: 4, b: ?, a: 1))(2, 3);
>
> This is also a reordering example. Just listing it to make it easier f=
or=20
> you to find.

thumbs-up.gif

> 4. Constant expressions
>
> I assume that =E2=80=9Cnested=E2=80=9D PFA will just work? A little mo=
re complex example=20
> would be good, just to showcase what's possible. How about:
>
>      public const BASE =3D 10;
>
>      private \Closure $arrayToInt =3D \array_map(\intval(?, self::BASE=
),=20
> ?),
>
> My understanding is that this should be valid.

Mine as well.  I'll add that example, and if Arnaud corrects me we can d=
eal with it then. :-)

> 5. Implementation notes and optimizations
>
> // Transpiles into:
>
> The `static` should definitely be added here, since you are specifical=
ly=20
> talking about internal details.
>
> 6. Scoping
>
> Seeing the scoping section: Is it possible to partial a `parent::` cal=
l?=20
> I never tried with FCC.

I... have no idea.  Presumably?  I'll add it and wait for Arnuad to yell=
 at me if not. :-)

> All minor clarification bits. I'm super happy with the proposed=20
> semantics once the =E2=80=9Creordering=E2=80=9D question is resolved.

Huzzah!

--Larry Garfield