Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:104738
MIME-Version: 1.0
References: <CAF+90c9YZcrquGfS4h3x1a+codkCFLarAThsOXcN69RCTvbAFA@mail.gmail.com>
 <CAAwdEzCgJjRsBF9Ecd00sDu9YuFJVKA-kE_o08nzBP8zHq_1-Q@mail.gmail.com> <CALKiJKrPL5zZhrHcT2ouuXOf-_V8HDVqEYPe6VreX_Nqdu6TqQ@mail.gmail.com>
In-Reply-To: <CALKiJKrPL5zZhrHcT2ouuXOf-_V8HDVqEYPe6VreX_Nqdu6TqQ@mail.gmail.com>
Date: Fri, 15 Mar 2019 11:10:40 +0100
Message-ID: <CAF+90c9agk=LtD-e_pJA2awUVh8z+sqVsNeXMkdV=3-LYZNZ3Q@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000041302605841f412e"
Subject: Re: [PHP-DEV] [RFC] Arrow functions / short closures
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000041302605841f412e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Mar 15, 2019 at 10:31 AM Rowan Collins <rowan.collins@gmail.com>
wrote:

> On Fri, 15 Mar 2019 at 09:01, Alexandru P=C4=83tr=C4=83nescu <drealecs@gm=
ail.com>
> wrote:
>
> > My question would be: whatever syntax we are going to use that has arro=
w
> > syntax, let's say *$f =3D \($x) =3D> $x * 2;* are we going to also supp=
ort
> the
> > arrow block version?:
> > *$f =3D \($x) =3D> {*
> > *    // more operations that will have better visible on multi-line*
> >
> > *    return $x * 2;*
> > *}*
> >
>
>
> See "Future Scope" in the RFC:
>
> > This feature is omitted in this RFC, because the value-proposition of
> this syntax is much smaller: Once you have multiple statements, the
> relative overhead of the conventional closure syntax becomes small.
>
> We shouldn't pick a syntax that rules it out, but it can be added later,
> with a separate RFC to discuss the benefits and details.
>

It might be worth giving some consideration to the possibility of
introducing this syntax already in this RFC. The main problem with punting
this off for later is that it may be necessary to refactor closures between
the short and the long form regularly: You need an extra statement in the
closure? You have to switch closure types, and also not forget to write our
the use() list this time.

On the other hand, allowing a block body for the closure does add a number
of complications to this proposal:

1. Syntax choice. Given the fn() syntax, we could go for either fn() {} or
fn() =3D> {}.

2. By-ref binding: While by-reference binding is not useful for
single-expression closures, there will be cases where it's needed for block
closures. We will also need to choose a syntax to opt-in to by-reference
binding. The RFC suggests use(&), which is somewhat non-great.

3. Determining bound variables. For single-expression closures we can get
away with binding all variables that are used inside the closure. Writing
something like fn() $a =3D $b might cause an unnecessary binding of $a, but
it's also a very contrived situation. For block closures performing
assignments inside the closure will be much more common and will need some
more consideration to avoid unnecessary bindings.

Regards,
Nikita

--00000000000041302605841f412e--