Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129283
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 17 Nov 2025 11:08:17 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <9b72757b-6071-4df5-9efd-8c0c0390f571@app.fastmail.com>
In-Reply-To: 
 <AM8P250MB017008AE323F366958B04B59E2C9A@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
References: <b2f466e6-b9d8-4aec-a275-e7ae7c4b67ff@app.fastmail.com>
 <2d6318f2-bd79-4aeb-a5b2-9db9367a8f27@app.fastmail.com>
 <AM8P250MB017008AE323F366958B04B59E2C9A@AM8P250MB0170.EURP250.PROD.OUTLOOK.COM>
Subject: Re: [PHP-DEV] [RFC] Partial Function Application v2
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Mon, Nov 17, 2025, at 10:26 AM, Bob Weinand wrote:
> Hey Larry,
>
> On 16.11.2025 21:51:59, Larry Garfield wrote:
>> On Sat, Jun 28, 2025, at 12:06 AM, Larry Garfield wrote:
>>> Hi folks.  Arnaud and I would like to present take-2 at Partial
>>> Function Application.
>>>
>>> https://wiki.php.net/rfc/partial_function_application_v2
>>>
>>> It is largely similar to the previous PFA proposal from 2021, though
>>> there are a number of changes.  Most notably:
>>>
>>> * 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.
>>>
>>> Note: We realize that this is a non-trivial RFC coming late in the
>>> cycle.  We are proposing it now because, well, it's ready now.  If the
>>> discussion 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, we're also OK with targeting 8.6 instead.  We'll see how
>>> that goes.
>>>
>>> <floor opens for discussion, Larry falls through the trap door>
>> It's been just over 2 weeks since the last comment in the thread, and the last change was made (allowing for parameter reordering).  Please consider this the Intent to Vote post; I'll be calling the vote sometime probably late Tuesday or on Wednesday, baring any new issues before then.
>>
>> --Larry Garfield
>
> I've just gave the RFC another deep read, and found only mentions of 
> pass-by-ref. But not return-by-ref, and neither does the implementation 
> handle this case:
>
> # ./sapi/cli/php -r 'function &r(&$a) { return $a; } $a = 1; $b = 
> &r($a); ++$b; var_dump($a);'
> int(2)
> # ./sapi/cli/php -r 'function &r(&$a) { return $a; } $a = 1; $b = 
> &r(?)($a); ++$b; var_dump($a);'
>
> Notice: Only variables should be assigned by reference in Command line 
> code on line 1
> int(1)
>
> Was this an oversight or intentionally omitted in the RFC? If it was, 
> I'd like to hear the reasoning on this.

Just an oversight.  We both use return-by-ref so rarely we forgot it's even a thing. :-)  I've updated the RFC to include it, and Arnaud said it's easy to update the implementation so will do so shortly.  Thanks for the catch.

As this is largely just a forgotten case (I just added a "/return-by-ref" to the text), I'm not sure if it needs a cooldown reset.  For the moment I will plan to continue opening the vote in the next few days, but if someone requests it I'll mark it a minor change and delay a week.

--Larry Garfield