Den 2021-06-18 kl. 16:08, skrev Nikita Popov:
On Wed, Jun 16, 2021 at 6:17 PM Larry Garfield <la...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php