Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128187
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 23 Jul 2025 10:56:42 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Partial Function Application v2
In-Reply-To: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
Message-ID: <52dbe5236df460958644677c781513c3@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-06-28 07:06, schrieb Larry Garfield:
> https://wiki.php.net/rfc/partial_function_application_v2

I've now given the RFC an in-depth read. I have the following remarks:

1.

>  If the function is variadic, there are two additional rules:
> 
> - Any positional placeholders that run into the variadic portion become 
> required.
> - If any positional placeholders run into the variadic portion, all 
> prior remaining placeholders become required. However, those parameters 
> may not be called with named arguments, as there is no name to use.

I do not understand what “running into the variadic portion” means. An 
example would probably be helpful. The first bullet point is probably 
intended to mean the following:

     function foo($a, ...$b) { }
     $pfa = foo(?, ?, ?, ?);

Now `$pfa` has 4 required parameters, despite `foo()` only having 1?

But I don't understand what the second bullet point is intended to say.

2.

In the placeholder semantics section:

>  While in theory that means a call like this would be legal:

 From what I see this specific case is not part of the examples section 
either. Including the desugaring of this extreme case would certainly 
help understanding.

3.

In the “Examples” section:

The choice of parameters names makes it hard to understand the examples, 
particularly when named parameters are used to provide arguments out of 
order. Including the “position” in the name of the parameter would make 
it easier to follow the example, since it is not necessary to look up 
the signature of `stuff()` all the time. (it becomes manageable if you 
read it as a sentence "is FPM")

4.

In the “Examples” section:

Is the “thunk” example accurate? It's the only example where the 
resulting “PFA” includes a variadic picking up the remaining arguments.

5.

In the “Examples” section:

> $c = stuff(?, p: $point, f: ?, s: ?, m: 4);

It is unexpected to me that this definition will take `$s` before `$f` 
in the resulting Closure. The explanation says that the “order does not 
matter”, but it is certainly unexpected that the order *changes* during 
desugaring.

In fact, the "(four(c: ?, d: 4, b: ?, a: 1))(2, 3);" example further 
down below seems to contradict this.

6.

In the “Extraneous arguments” section:

I disagree with silently ignoring trailing arguments, because it *adds* 
to the existing inconsistency between userland and internal functions. 
In fact there was a recent-ish discussion (I would provide a link, but 
can't find it right now) about allowing userland functions to define 
that they want to be called with a strict arity.

While it would add to the symbol soup, having an explicit “ignore the 
argument at this position” indicator would be useful. For example: 
`$firstNonZero = array_find($arr, intval(?, _));` (I understand this 
specific one doesn't work, because `_` is a valid constant).

7.

It is not clear to me from the RFC, why the `...` placeholder to 
indicate “all remaining arguments” must come between positional and 
named parameters. It would make more sense to me for it to become last, 
because it would also make it clearer that named parameters take 
priority over `...`. Is there some technical limitation that caused this 
choice to be made?

Best regards
Tim Düsterhus