Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:105306 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 34562 invoked from network); 17 Apr 2019 13:19:06 -0000 Received: from unknown (HELO mail-it1-f194.google.com) (209.85.166.194) by pb1.pair.com with SMTP; 17 Apr 2019 13:19:06 -0000 Received: by mail-it1-f194.google.com with SMTP id s3so3684177itk.1 for ; Wed, 17 Apr 2019 03:17:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7Tyv/aG6iTnwVjaE9xcx8chvP3DC5ud8a0vx3bqJRWI=; b=VCDsljFALfgoFdHdDGYEynPIjzLYhGwKzSf7KpKuUQ+8qUUtKurC9y+DuhnMfhvI0u SiONwF25p9ymYmYKDrRLQ2iBkB46SXkpbreLRdEeVm5J7AYvjSr2XogEu0hpEiAD4yIQ OQr49ZYqbAgGPxRRhLeVsNZ5Fl8XypMU+g1pQFHV/tXGm9aTwijN45I0+ARq4qgu9KvJ dOgSsgehH5rITP00RNATdQO8e4L+5GCXgeNzhrXfeHVvymnRxSNS5jV7un8xsqGLxDPM XboCPjhhjERHroZTgG21aR5tD7Q7uGoxJdl1KTSrBjWCN4Sr3rq3eMW550kRxi3wuBIY aiIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Tyv/aG6iTnwVjaE9xcx8chvP3DC5ud8a0vx3bqJRWI=; b=BqKtdMo3AqMJBPIN568ldpRvKLZPbFB0HQhzbVIyxeZieHwt9mr7WHXX4mpBqB54F9 qHeBJLjlIvCfbt7Wd8VKdoDPiVs78z92fCt4811lR5z7Gx+tob/26j4H8Io1EfAsEX3m iMBWmXOGQ6SjDei3RJlxZxrrkRAeaViYaM+PS+Vh9vc3e1WJz/SdihqWjntAhPBuPREt YJGFH6kD2IiVWKN+4YuYt//dh1aX1TQ4MM+haKYhzqVC3WcqAh2nXPsXoOmwvm70ABLR RVYAi9Ws8fZoItxjYQ6MBaQjMfDBjDOOva8hCqbEYA8bYXOyjIK1izcPJf+m13BQ+kns XZnw== X-Gm-Message-State: APjAAAWznUJ+nVfPT4Lq5SnVwTaT8MlKZouZYfkSl6MZ8+gYsMjW5fCh P/mDsf5KOqIwAQfsTi0vHlXdabjJVe83g76YOT8= X-Google-Smtp-Source: APXvYqzIm3LnNdYcq9ZfnntuowLxZoPHwtGVJkbJvRAU3byOM529NkbLFhPpnVwnr5kobtX9YmoTJYZevOLgnY1vNCo= X-Received: by 2002:a24:9197:: with SMTP id i145mr32240918ite.117.1555496278345; Wed, 17 Apr 2019 03:17:58 -0700 (PDT) MIME-Version: 1.0 References: <51b7c183-f47a-e5e2-bd3d-159e39ce88c5@telia.com> In-Reply-To: <51b7c183-f47a-e5e2-bd3d-159e39ce88c5@telia.com> Date: Wed, 17 Apr 2019 12:17:41 +0200 Message-ID: To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000001ecd320586b7336b" Subject: Re: [PHP-DEV] Re: [RFC] Arrow functions / short closures From: nikita.ppv@gmail.com (Nikita Popov) --0000000000001ecd320586b7336b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Apr 17, 2019 at 11:23 AM Bj=C3=B6rn Larsson wrote: > 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 us= es > >>> the syntax > >>> > >>> fn($x) =3D> $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 vot= e. > >> 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 agains= t > >> "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 aroun= d > > different syntax choices, with the main contenders being fn, \ and =3D= =3D>. > > > > fn($x) =3D> $x > > fn($x, $y) =3D> $x*$y > > > > \$x =3D> $x > > \($x, $y) =3D> $x*$y > > > > $x =3D=3D> $x > > ($x, $y) =3D=3D> $x*$y > > > > I think the main qualities of these possibilities are: > > > > * Implementation complexity: fn and \ are easy, =3D=3D> is hard (lexe= r > 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?) > > > > At this point I'm considering to either a) move forward with fn() as th= e > > 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 --0000000000001ecd320586b7336b--