Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99287
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.223.176 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <d6741c05-f014-c23a-ced8-2cddd76a078b@telia.com>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <alpine.DEB.2.20.1705302038520.2232@singlemalt.home.derickrethans.nl> <d6741c05-f014-c23a-ced8-2cddd76a078b@telia.com>
Date: Tue, 30 May 2017 16:26:45 -0600
Message-ID: <CAFMT4NpJqDg1W-jSXFcgL3PGj--gbr+QTFdXAu+z-WK1xjMdHA@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: Derick Rethans <derick@php.net>, 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 3:37 PM, Bj=C3=B6rn Larsson
<bjorn.x.larsson@telia.com> wrote:
> Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
>
>> On Tue, 30 May 2017, Levi Morrison wrote:
>>
>>> 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 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) =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?
>>
>> I think 5 is terrible from a readability point of view. As you said it:
>> "symbol soup".
>
> Do you think having =3D=3D> instead of =3D> would make it less of a
> symbolic soup?

If something is already symbol soup how does adding another symbol
make it less so?