On Wed, Apr 17, 2019 at 11:23 AM Björn Larsson <bjorn.x.lars...@telia.com> wrote:
> Den 2019-04-14 kl. 18:52, skrev Nikita Popov: > > On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov <nikita....@gmail.com> > wrote: > > > >> 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 > >> > > So, there's been quite a bit of extra discussion here... unfortunately I > > can't say that it really clarified anything, we're still circling around > > different syntax choices, with the main contenders being fn, \ and ==>. > > > > fn($x) => $x > > fn($x, $y) => $x*$y > > > > \$x => $x > > \($x, $y) => $x*$y > > > > $x ==> $x > > ($x, $y) ==> $x*$y > > > > I think the main qualities of these possibilities are: > > > > * Implementation complexity: fn and \ are easy, ==> is hard (lexer > hack). > > * Availability of reduced syntax: \ an ==> have a special > single-argument > > syntax, fn doesn't. > > * Obviousness/readability: fn and ==> are obvious, while \ is not. > > Especially \$x => $x looks quite obscure to the uninitiated (is that a > > variable escape, like it would be in strings?) > > > > At this point I'm considering to either a) move forward with fn() as the > > choice I'd consider most likely to gather a consensus or b) have a > > secondary three-way vote between these three syntax choices. > > > > Nikita > > Hi again , > > I came to think on BC impact of fn() syntax. The RFC mentions > 12 matches and 1 in namespaces. Should one conclude that > the BC impact is low or is their other aspects to consider? I > myself uses fn as a dummy function name when writing > "test" code. > Yes, the impact is expected to be pretty much limited to my https://github.com/nikic/iter library (where I will rename the namespace in the upcoming 2.0 version) and test code. Nikita
