Hi Brent, On 06/10/2020 09:53, Brent Roose wrote:
We can have the discussion again on whether we like short closures or not, but it turned out most of internals_and_ userland devs do — based on the vote count in the sigle line RFC and the reaction on Nuno's PR, as well as my experience from an OSS maintainer point of view.
I don't know how much of the earlier discussion you saw at the time, or have looked back at, but it's worth noting that the arrow functions RFC which passed voting came after several long mailing list threads, and several complete rewrites of the proposal, at least one of which went to vote and was declined. The lack of multi-statement arrow functions wasn't an accident, it was part of how consensus was achieved.
That doesn't mean we can't discuss multi-statement arrow functions now - they were listed as "Future Scope", and we are now in that Future. :) However, it does mean a new RFC doing so needs to set out its own justification, not assume that everyone who voted Yes on the previous RFC will vote Yes on this one as well.
Furthermore, the `use(*)` syntax misses the point of this proposal: it's not about being able to use all variables from the outer scope, it's about a clean syntax that's as short as possible
Rather than "missing the point", I think it's a case of different people wanting different things from arrow functions. In one of the previous discussions [1] I suggested three perspectives of what people wanted them for:
(a) an improved syntax for declaring closures (in the way that [$foo, $bar] is a shorter syntax for array($foo, $bar)) (b) improved *semantics* for declaring closures, where you don't have to list the variables to be captured (c) a new kind of closure designed for specific use cases, with its own syntax and semantics
Those who wanted (c) are generally happy with what we have, with perhaps an interest in making more statements available as expressions, such as throw [2] and match [3].
Those who wanted (b) generally see the arrow syntax as a means to an end, and are open to alternative syntaxes that achieve the relevant semantics, such as use(*).
Those who wanted (a) may see things the other way around: the short syntax is the goal, and auto-capture and implicit return are just the ways to achieve that goal.
There's probably no way to please all three groups (and the various combinations and nuances I've over-simplified), but it's useful to acknowledge the existence of those who want *some* of what you want, but don't agree on all of it.
I look forward to seeing the RFC if Nuno decides to proceed with it, because I am much more interested in how it will affect *users* of PHP than the technical details visible in the PR.
[1] https://externals.io/message/98045#98209 [2] https://wiki.php.net/rfc/throw_expression [3] https://wiki.php.net/rfc/match_expression_v2 Regards, -- Rowan Tommins (né Collins) [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
