Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:105306
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CAF+90c_keZTbMTuDO+9WRa53MsYxbNxkMO_pxGyymGnxCp691g@mail.gmail.com>
 <CAF+90c8yJkuJYuRZZrbnJ1rv7xOv+zUuevP9B+fpok960VQxcw@mail.gmail.com> <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: <CAF+90c-dzdx6piUY3z+ye8tX_asZW9X4sfnQqmf5F7ry8VbkdQ@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: PHP internals <internals@lists.php.net>
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 <bjorn.x.larsson@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.ppv@gmail.com>
> wrote:
> >
> >> On Wed, Mar 13, 2019 at 4:56 PM Nikita Popov <nikita.ppv@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 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--