Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114978
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>,
 Larry Garfield <larry@garfieldtech.com>
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
 <CAF+90c-tnTMUyVDu=iheB3oL_Q6nuT+1aQgcw27xv_ZcQiDrkQ@mail.gmail.com>
Reply-To: =?UTF-8?Q?Bj=c3=b6rn_Larsson?= <bjorn.x.larsson@telia.com>
Message-ID: <45b16626-2b04-404b-f5f9-2430004bbdc8@telia.com>
Date: Mon, 21 Jun 2021 16:26:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAF+90c-tnTMUyVDu=iheB3oL_Q6nuT+1aQgcw27xv_ZcQiDrkQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: sv
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: internals@lists.php.net ("Björn Larsson via internals")

Den 2021-06-18 kl. 16:08, skrev Nikita Popov:
> On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield <larry@garfieldtech.com>
> wrote:
> 
>> Hi folks.  The vote for the Partial Function Application RFC is now open,
>> and will run until 30 June.
>>
>> https://wiki.php.net/rfc/partial_function_application
>>
>> Of particular note, a few people had asked about using ...? instead of ...
>> for the variadic placeholder.  In the end we decided not to explore that,
>> as Nikita explained off-list it was actually more confusing, not less, as
>> it would suggest "placeholder for a variadic" rather than "a placeholder
>> that is variadic."  Otherwise, it's just more typing.  The syntax choices
>> section of the RFC has been updated accordingly.
>>
> 
> A couple of notes on the content (or non-content) of the RFC:
> 
> * The behavior of nullsafe calls with PFA has been brought up in the
> discussion, but is not mentioned in the RFC. For reference, $foo?->bar(?)
> is the same as $foo !== null ? $foo->bar(?) : null. I don't think the
> behavior is particularly unreasonable, but I also think it's not
> particularly useful and may be surprising (in that there is a plausible
> alternative behavior). I think you may have been better off forbidding that
> case.
> 
> * The behavior of parameter names / reflection with regard to variadic
> parameters is very odd. For function test(...$args) and test(?, ?, ?) you
> get back a function that nominally has three parameters with the name
> $args. Parameter names in PHP are generally required to be unique, and of
> course this also has implications for named arguments, for example this
> works, while it probably shouldn't:
> https://3v4l.org/cQITD/rfc#focus=rfc.partials To be honest, I'm not sure
> what the right way to handle this is, but I don't think this is it. A
> possibility would be to bring back the concept of name-less parameters we
> had prior to PHP 8 (for internal functions only), or possibly to make the
> signature less precise by simply retaining an ...$args parameter, and just
> making the enforcement of "at least three parameters" an implementation
> detail. The latter seems like the best option.
> 
> * The RFC doesn't specify how PFA interacts with strict types. If I create
> a partially-applied function in strict_types=1 file and call it in a
> strict_types=0 file, what happens? Will it use strict_types=0 semantics,
> including for arguments that were bound in the strict_types=1 file?
> 
> * It's worth noting that the "new Foo(?)" syntax will create and destroy a
> Foo object as part of creating the partial (not just a call to the
> partial). I've mostly convinced myself that this is *probably* harmless. It
> would have interacted negatively with an earlier version of
> https://wiki.php.net/rfc/new_in_initializers, but I think the problem there
> was not on the side of partials.
> 
> In any case, I'm voting no on this one: While PFA is simple on a conceptual
> level, the actual proposal is complex and has lots of tricky edge cases.
> Especially once you take a look at the implementation. I'm not convinced
> that PFA in its full generality is justified for inclusion in PHP.
> 
> Regards,
> Nikita
> 
Would you look on this feature in a different light if the above
concerns about strict types and nullsafe calls could be clarified /
solved? Or is it about the implementation with it's complexity and
tricky edge cases?

I myself think one should take into account that this is a feature
that would make PHP stand out even more. Not being a follower of
other languages here :-)

Regards //Björn L