Re: [RFC] First-class callable syntax

On 20.05.21 21:35, Larry Garfield wrote:

There's been a lot of rapid iteration, experimentation, and rejection. The most recent alternatives are this one from Levi: https://gist.github.com/morrisonlevi/f7cf949c02f5b9653048e9c52dd3cbfd And this one from me: https://gist.github.com/Crell/ead27e7319e41ba98b166aba89fcd7e8 The main takeaways (to give context to Nikita's proposal): * Because of optional arguments, using the same symbol for "copy one parameter from the underlying function" and "copy all remaining parameters from the underlying function" is not viable. It runs into oddball cases where you may intend to only use one argument but end up using multiple, especially in array operation functions that sometimes silently pass keys along to callbacks if they can. Hence the separate ? and ... that were proposed. * Named arguments make things more complicated. One of the questions is whether named placeholders should be supported or not. And if they are, does that mean you can effectively reorder the arguments in the partial application, and what does that mean for usability. It gets complicated and scope-creepy fast. * The most important use cases are: ** "prefill nothing, just give me a callable" (which is the case Nikita's RFC covers) ** "reduce an arbitrary function to a single remaining argument", which lets it be used by various existing callback functions in the standard library (array_map, array_filter, etc.), many user-space APIs, and the pipes RFC that I am planning to bring back up once PFA is figured out (https://wiki.php.net/rfc/pipe-operator-v2). While there are other use cases, the two of those cover the vast majority of uses. (There is some dispute about which of those is larger, or will be larger in the future.) It took a while to realize the first point, which basically killed "? means zero or more". We also went down a rabbit hole of trying to make argument reordering work because some people asked for it, but as noted that's a very deep rabbit hole. My gist above was a reduced-scope version of Levi's that uses two symbols and drops named placeholders. It doesn't give us every possible combination, but it does give us most reasonable combinations. Nikita's "just do the first one" RFC (this thread) was proposed at about the same time, and takes an even-further scope reduction. My own take is that the PFA discussion has been overly-bikeshedded, which is unfortunate since I think we're quite close to now having a workable answer that covers most reasonable use cases. While I agree Nikita's RFC here would be an improvement over 8.0, I don't think throwing in the towel on PFA yet is a good idea. It's a much more robust and powerful approach that still gets us the "first class callable" syntax we all want (at least I assume we all do), and lots of additional power to boot. I'd rather see us try to drive PFA home to completion. If that proves impossible by early July, then this RFC would still get us something this cycle, as long as the syntax is still compatible with PFA. (Otherwise whenever PFA gets sorted out in the future we end up with yet-more-ways to do the same thing that are not optimizations of each other but just competing syntax, in which case no one wins.)

I think Levis proposal and the two symbols ... and ? are a really good improvement to the previous PFA RFC (Nikitas/Joes RFC is a good first step in that direction). I do think named arguments are important, but reordering arguments could be confusing and are not necessary (and if named arguments are used for the PFA, it would make sense to use named arguments for calling it too). Another big reason for me why I like Levis proposal more is that he still includes partially applying the new operator. Although the semantics of the new operator are a bit different from regular functions, it would be very handy to support this special case. array_map is an obvious application: $productObjects = array_map(new Product(?, ?, ?), $productIds, $currencies, $prices); But other usages would probably pop up, like abstracting away dependencies of classes by pre-setting those via PFA, like: $productFactory = new Product($dependency1, $dependency2, ...); $productObjects = array_map($productFactory, $productIds, $currencies, $prices); I really like this because from a users perspective this seems very clear and readable to me, even though from the PHP language perspective it might be more messy. About the bikeshedding: Using "..." as a symbol does make sense to me, as variadic unpacking/variadic arguments have a similar connotation (referring to an unknown/arbitrary amount of elements). * was also suggested (as in "somefunction(*)" instead of "somefunction(...)"), and I like that too - * in regex is any amount of elements (even zero), and ? is exactly one placeholder in SQL. As many PHP developers know regex and SQL this would make PFA code a lot easier to understand even if someone is not that familiar with it yet.