Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99279
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.156 cause and error)
To: Levi Morrison <levim@php.net>
Cc: PHP internals <internals@lists.php.net>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <301641f7-57fc-7a9c-90da-4fd4e4126cff@telia.com>
 <CAFMT4NqZ=sPxrs4su5W-WRh5Bz8p_aV4E=MvZ6_gJoRA0hQNQw@mail.gmail.com>
Message-ID: <0925cccf-b2a9-e5e8-b222-86cf582c5d35@telia.com>
Date: Tue, 30 May 2017 21:15:03 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAFMT4NqZ=sPxrs4su5W-WRh5Bz8p_aV4E=MvZ6_gJoRA0hQNQw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2017-05-30 kl. 20:24, skrev Levi Morrison:
> On Tue, May 30, 2017 at 12:16 PM, Björn 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) => expr
>>>     2. function(params) => expr
>>>
>>>     3. (params) ==> expr
>>>     4. (params) => 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) => expr     // binds no values
>>>        [=](params) => expr    // binds by value
>>>        [&](params) => 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) => $array[] = $x + $y
>>>         [=, &$array]($x) => $array[] = $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 are
>>> 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) => $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 `=` 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 say
>>> so confidently because sometimes there are things lurking in our
>>> grammar I forget about.
>>>
>> As I said in the old thread, option 5 with ==> instead of => might
>> be an option. I think that would mitigate the minor BC break.
>>
>> r//Björn
> 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 `==>` would not help here.
Ok, but how about having ==> to improve readability and make it
less ambiguous & quicker to read the code. Also enable the syntax:
- (params) ==> expr    // binds no values.

r//Björn