Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105282 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 98611 invoked from network); 15 Apr 2019 14:26:11 -0000 Received: from unknown (HELO v-smtpout3.han.skanova.net) (81.236.60.156) by pb1.pair.com with SMTP; 15 Apr 2019 14:26:11 -0000 Received: from [192.168.7.8] ([213.64.245.126]) by cmsmtp with ESMTPA id FzizhLaj0M0W3FzizhaaFr; Mon, 15 Apr 2019 13:24:33 +0200 To: Nikita Popov References: Cc: PHP internals Message-ID: <2abd0f71-f116-bf3f-7467-88bdc895d057@telia.com> Date: Mon, 15 Apr 2019 13:24:34 +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: MS4wfNNc9/NgCwp4e5XgAsLg5WE9ELtQHBOQHaIs5NfXjC1+6e22O0Hb1ZYD2QVCdVclWKrEBb/Ue/kto6CPp4N/73Y3lMrNwgVci75zD2Ej1u9DuRoI30hG MqCLFOXpDyjjn51hzg6FR6wtCPf0T9LFLM47mB7RXokyB63Sn448+svSPgq2KokQ1I89mUJ+jl9bXUfjosQsfVJWNKeVvMIptFol9XhWbY548glGLQ1gOQSN 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, Even if a consensus wasn't reached I feel that there has been quite a constructive discussion, where the pros and cons were drilled down for the syntax alternatives at hand. So having no voting rights myself, but alternative B for voting looks ok in my eyes. One could ask having three alternatives or two? OTOH, those three alternatives are now on the table and nothing else, so all three. But if implementation of ==> are much to overwhelming, only two. r//Björn L