Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99258
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain telia.com from 81.236.60.155 cause and error)
To: Levi Morrison <levim@php.net>, Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <97bb5051-6413-b78a-e981-ad8858caec4c@gmail.com>
 <8d4ee559-1ad2-4d65-ae4f-207e59f056e3@Spark>
 <61DC1C28-CAF2-45F4-8D9F-A66BEA2E90B1@gmail.com>
 <3942113e-f83a-444f-bbc2-462c70d67c65@Spark>
 <20db9b97-5313-057d-db56-920ccb758558@telia.com>
 <CAFMT4Noi3s1eB9Og-c3P=wnz646G=eeSmCASVF1q_JM-SVvZKA@mail.gmail.com>
 <877970f0-b22d-a8b9-9ad4-6fc9139a9b34@telia.com>
 <CAFMT4Nqyhv8-XaC7L8khHjGKRMW677AWeH8red2ogmCEYV-mSg@mail.gmail.com>
Message-ID: <c0971e49-3581-999c-4f8d-d9c3b9bce0f6@telia.com>
Date: Tue, 30 May 2017 10:30:02 +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: <CAFMT4Nqyhv8-XaC7L8khHjGKRMW677AWeH8red2ogmCEYV-mSg@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] Arrow Functions
From: bjorn.x.larsson@telia.com (=?UTF-8?Q?Bj=c3=b6rn_Larsson?=)

Den 2017-05-30 kl. 04:48, skrev Levi Morrison:

> On Mon, May 29, 2017 at 4:47 AM, Björn Larsson
> <bjorn.x.larsson@telia.com> wrote:
>> Den 2017-04-05 kl. 23:57, skrev Levi Morrison:
>>
>>>> Any plans to go with this for 7.2?
>>> I have been working on this RFC a bit in the last two weeks and intend
>>> to start voting within the next week.
>> Any hope this one will make it into PHP 7.2?
>>
>> Of course maybe it's prudent to have some more discussion
>> and then it's 7.3.
>>
>> Regards //Björn Larsson
>>
>> PS If there is some writing needed for the RFC itself maybe I
>> could assist, need to get an account & karma first though.
> Based on the discussion there are a few different syntax choices that
> we probably just need to vote between. 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]
>
> And of course it does have downsides:
>
>    - Symbols soup (it uses a lot of symbols)
>    - A minor BC break; the following piece which is guaranteed to be an
> error would now have meaning:
>
>        [](optional params)    // previously an error
>
> 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.
>
Well, my preference would be for alternative 3. Not in favour of 2 & 4.
Nr 1 not so sure about and for nr 5, maybe tweak it to:
- [](params) ==> expr    // binds no values
- [=](params) ==> expr    // binds by value
- [&](params) ==> expr    // binds by reference

Leaving out [] could also be a default:
- (params) ==> expr    // binds no values

I presume then that the options discussed earlier "|params| => expr"
and "lamda(params) => expr" are of the table.

r//Björn Larsson