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
