Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105284 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 8717 invoked from network); 15 Apr 2019 15:01:07 -0000 Received: from unknown (HELO mail1.25mail.st) (206.123.115.54) by pb1.pair.com with SMTP; 15 Apr 2019 15:01:07 -0000 Received: from [10.0.1.70] (unknown [49.48.243.62]) by mail1.25mail.st (Postfix) with ESMTPSA id E78F76059A; Mon, 15 Apr 2019 11:59:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) In-Reply-To: Date: Mon, 15 Apr 2019 18:59:20 +0700 Cc: PHP internals Content-Transfer-Encoding: quoted-printable Message-ID: <78D0E2CD-7778-4DB8-8DDC-9C82FE24389D@koalephant.com> References: To: Nikita Popov X-Mailer: Apple Mail (2.3445.104.8) Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures From: php-lists@koalephant.com (Stephen Reay) > On 14 Apr 2019, at 23:52, Nikita Popov wrote: >=20 > On Mon, Apr 8, 2019 at 4:06 PM Nikita Popov = wrote: >=20 >> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov = wrote: >>=20 >>> Hi internals, >>>=20 >>> Motivated by the recent list comprehensions RFC, I think it's time = we >>> took another look at short closures: >>>=20 >>> https://wiki.php.net/rfc/arrow_functions_v2 >>>=20 >>> This is based on a previous (withdrawn) proposal by Levi & Bob. It = uses >>> the syntax >>>=20 >>> fn($x) =3D> $x * $multiplier >>>=20 >>> and implicit by-value variable binding. This example is roughly >>> equivalent to: >>>=20 >>> function($x) use($multiplier) { return $x * $multiplier; } >>>=20 >>> The RFC contains a detailed discussion of syntax choices and binding >>> modes. >>>=20 >>> Regards, >>> Nikita >>>=20 >>=20 >> Heads up: I plan to start voting on this RFC tomorrow if nothing new = comes >> up. >>=20 >> 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) =3D> $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) =3D> $x*$y, but = I >> suspect that there are some people who are more strongly biased = against >> "sigil salad" than I am... >>=20 >> Nikita >>=20 >=20 > 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 = =3D=3D>. >=20 > fn($x) =3D> $x > fn($x, $y) =3D> $x*$y >=20 > \$x =3D> $x > \($x, $y) =3D> $x*$y >=20 > $x =3D=3D> $x > ($x, $y) =3D=3D> $x*$y >=20 > I think the main qualities of these possibilities are: >=20 > * Implementation complexity: fn and \ are easy, =3D=3D> is hard (lexer = hack). > * Availability of reduced syntax: \ an =3D=3D> have a special = single-argument > syntax, fn doesn't. > * Obviousness/readability: fn and =3D=3D> are obvious, while \ is not. > Especially \$x =3D> $x looks quite obscure to the uninitiated (is that = a > variable escape, like it would be in strings?) >=20 > 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. >=20 > Nikita As someone without voting rights (and thus you can take this with a = grain of salt), given what you=E2=80=99ve highlighted I believe your = option (a) is the obvious one: You said yourself, that `=3D=3D>` is a more complex/hard implementation = (which is bad) and that `\` is non obvious/obscure, and (IMO) it=E2=80=99s= worse as far as readability goes. As I=E2=80=99ve said before, I expect to use this feature (if it passes) = very little if at all, but I still appreciate that `fn()...` keeps = reasonably-familiar/obvious syntax, because even if I choose not to = write using this feature, I=E2=80=99ll invariably have to read someone = else=E2=80=99s code that does use it. Cheers=20 Stephen=20