Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105305 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 19793 invoked from network); 17 Apr 2019 12:24:40 -0000 Received: from unknown (HELO v-smtpout1.han.skanova.net) (81.236.60.154) by pb1.pair.com with SMTP; 17 Apr 2019 12:24:40 -0000 Received: from [192.168.8.9] ([94.254.95.82]) by cmsmtp with ESMTPA id GgmwhhWDbSq0xGgmxhFy7v; Wed, 17 Apr 2019 11:23:31 +0200 To: Nikita Popov References: Cc: PHP internals Message-ID: <51b7c183-f47a-e5e2-bd3d-159e39ce88c5@telia.com> Date: Wed, 17 Apr 2019 11:23:33 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-CMAE-Envelope: MS4wfMbuyjREsPx0mk0SB3tmxymVP6EOqBhHjbKu8x92Ls2ZAWfcUGocVjfv810Pn+5GpThNGHzDMypffxQFwdMYAlzeYnboKY1vN8qnXEm1v5htU3OQ3m3g aTrViHh82mBEDLsxK9o1NAWDFKvKux/0ePMcnoDBWD3nTiiFlUdmD+2B6f66iFZoAD5Fgv0DruSb6t/jHMZxb1C3kJxjpWrrMc0= Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=) Den 2019-04-14 kl. 18:52, skrev Nikita Popov: > On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov wrote: > >> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov 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. r//Björn L