Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114952
MIME-Version: 1.0
References: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
In-Reply-To: <222b3921-3d9b-47f9-8d13-e6a123f36fad@www.fastmail.com>
Date: Fri, 18 Jun 2021 16:08:33 +0200
Message-ID: <CAF+90c-tnTMUyVDu=iheB3oL_Q6nuT+1aQgcw27xv_ZcQiDrkQ@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e1873405c50adcc0"
Subject: Re: [PHP-DEV] [Vote] Partial Function Application
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000e1873405c50adcc0
Content-Type: text/plain; charset="UTF-8"

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

--000000000000e1873405c50adcc0--