On Tue, Apr 9, 2019 at 8:56 AM Björn Larsson <bjorn.x.lars...@telia.com> wrote:
> Den 2019-04-08 kl. 16:06, skrev Nikita Popov: > > > On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov <nikita....@gmail.com> > wrote: > > > >> Hi internals, > >> > >> Motivated by the recent list comprehensions RFC, I think it's time we > took > >> another look at short closures: > >> > >> https://wiki.php.net/rfc/arrow_functions_v2 > >> > >> This is based on a previous (withdrawn) proposal by Levi & Bob. It uses > >> the syntax > >> > >> fn($x) => $x * $multiplier > >> > >> and implicit by-value variable binding. This example is roughly > equivalent > >> to: > >> > >> function($x) use($multiplier) { return $x * $multiplier; } > >> > >> The RFC contains a detailed discussion of syntax choices and binding > modes. > >> > >> Regards, > >> Nikita > >> > > Heads up: I plan to start voting on this RFC tomorrow if nothing new > comes > > up. > > > > Most of the discussion was (as expected) about the choice of syntax. > > Ultimately I think there are many reasonable choices we can make here, > but > > we should stick to a specific proposal for the purposes of the RFC vote. > > None of the given arguments convinced me that some other syntax is > > *strictly* better than the proposed fn($x, $y) => $x*$y -- it's more a > > matter of some choices being slightly better in one case and slightly > worse > > in another. My personal runner-up would be \($x, $y) => $x*$y, but I > > suspect that there are some people who are more strongly biased against > > "sigil salad" than I am... > > > > Nikita > Hi, > > I recall that the perception of the ==> syntax in the Hacklang user > community was quite positive. Of course it was implementation > difficulties. Are they still to cumbersome in PHP? > > Personally I prefer that one being more readable or the \ one. > Anyway, glad to see that short closures finally is on the road > again! > The ==> syntax is the other one I implemented ( https://github.com/php/php-src/pull/3945). The implementation is based on lexer lookahead, which is ugly but still manageable. I haven't seen much support for this variant in this discussion though. And of course, if there's no strong preference for ==>, I'd rather go with the variant that is easier for us (and all 3rd party tooling) to support from a technical perspective. Nikita
