Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99276
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.43 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAF+90c-gzHRJWZCMkfZG-0t56qqPfmtUqYi5tSOWNP=_YMfwhQ@mail.gmail.com>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <301641f7-57fc-7a9c-90da-4fd4e4126cff@telia.com> <CAFMT4NqZ=sPxrs4su5W-WRh5Bz8p_aV4E=MvZ6_gJoRA0hQNQw@mail.gmail.com>
 <CAF+90c-gzHRJWZCMkfZG-0t56qqPfmtUqYi5tSOWNP=_YMfwhQ@mail.gmail.com>
Date: Tue, 30 May 2017 12:43:31 -0600
Message-ID: <CAFMT4NpVm4MQkNvOHVtsMwsd1Y5NPHtPEftR4UWR5DXdhMqOkg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: levim@php.net (Levi Morrison)

On Tue, May 30, 2017 at 12:36 PM, Nikita Popov <nikita.ppv@gmail.com> wrote=
:
> On Tue, May 30, 2017 at 8:24 PM, Levi Morrison <levim@php.net> wrote:
>>
>> On Tue, May 30, 2017 at 12:16 PM, Bj=C3=B6rn Larsson
>> <bjorn.x.larsson@telia.com> wrote:
>> > Den 2017-05-30 kl. 19:58, skrev Levi Morrison:
>> >>
>> >> Internals,
>> >>
>> >> The previous discussion thread has died down significantly and so I'd
>> >> like to start a new one to refocus. This message has some redundant
>> >> information by design so people don't have to reference the other
>> >> thread so much.
>> >>
>> >> Based on the discussion there are a few different syntax choices
>> >> people liked. Overall it's a feature that people seem to want but
>> >> everyone seems to prefer a different syntax choice.
>> >>
>> >>    1. fn(params) =3D> expr
>> >>    2. function(params) =3D> expr
>> >>
>> >>    3. (params) =3D=3D> expr
>> >>    4. (params) =3D> expr
>> >>
>> >> Note that 3 and 4 require a more powerful grammar and parser and that
>> >> 4 has ambiguities. I think we can work around them by rules -- only
>> >> mentioning it because its popular because of JavaScript and do not
>> >> prefer this at all.
>> >>
>> >> Note that 1 requires a new keyword.
>> >>
>> >> Option 2 looks the best from that perspective but is by far the
>> >> longest; remember people are partially interested in this feature
>> >> because they want shorter closures which this doesn't really help.
>> >>
>> >> This is why everyone is so divisive. All options have drawbacks.
>> >> Additionally some people don't like binding by value and would prefer
>> >> ref, and others really would be against by-ref.
>> >>
>> >> Which brings me to an option I don't think was ever discussed on list=
:
>> >>
>> >>    5.
>> >>       [](params) =3D> expr     // binds no values
>> >>       [=3D](params) =3D> expr    // binds by value
>> >>       [&](params) =3D> expr    // binds by reference
>> >>
>> >> It has quite a few good qualities:
>> >>
>> >>    - No new keywords
>> >>    - Can choose between reference and value
>> >>    - Concise
>> >>    - Has precedence in C++, a major language
>> >>    - Can be done in our existing grammar and parser[1]
>> >>    - Can be extended to allow explicit binding of variables:
>> >>        // all equivalent
>> >>        // y is bound by value, array by reference
>> >>        [&, $y]($x) =3D> $array[] =3D $x + $y
>> >>        [=3D, &$array]($x) =3D> $array[] =3D $x + $y
>> >>
>> >> And of course it does have downsides:
>> >>
>> >>    - Symbol soup (it uses a lot of symbols)
>> >>    - A minor BC break. Empty arrays which are invoked as functions ar=
e
>> >> currently guaranteed to be errors at runtime and would have a new
>> >> valid meaning. Here's an example from inside an array literal:
>> >>
>> >>        // error at runtime previously
>> >>        [ []($x) =3D> $x ]
>> >>        // now an array with one item which is a closure that returns
>> >> its parameter
>> >>
>> >> Sara pointed out that we'd need to keep a leading `=3D` or `&` in the
>> >> array to disambiguate from our array closure form.
>> >>
>> >> Overall I'd prefer 1 or 5. What do you guys think?
>> >>
>> >>
>> >>    [1]: I'm pretty sure it can be done but until it's done I can't sa=
y
>> >> so confidently because sometimes there are things lurking in our
>> >> grammar I forget about.
>> >>
>> > As I said in the old thread, option 5 with =3D=3D> instead of =3D> mig=
ht
>> > be an option. I think that would mitigate the minor BC break.
>> >
>> > r//Bj=C3=B6rn
>>
>> The compatibility issue is with `[](params)` is that it is currently
>> an empty array literal that will be invoked; this is guaranteed to be
>> an error at runtime so it is unlikely to cause much trouble. A
>> trailing `=3D=3D>` would not help here.
>
>
> You mentioned ability to explicitly specify binding as a possible extensi=
on.
> However
>
>     [$var1, $var2]()
>
> is not necessarily failing right now, it may be a valid array callable.
>
> Nikita

As already mentioned we must maintain a leading `=3D` or `&`:

  [=3D, $var1, $var2]()
  [=3D, $var1, $var2]()

Sorry if that was unclear.