Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99360
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain mindplay.dk from 74.125.83.43 cause and error)
MIME-Version: 1.0
In-Reply-To: <6357d97c-3f2e-4cf8-cb1f-cb7f7ccccf7c@telia.com>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <DM3PR18MB07641E547AD2FA1DFA5BEF65DEF60@DM3PR18MB0764.namprd18.prod.outlook.com>
 <6357d97c-3f2e-4cf8-cb1f-cb7f7ccccf7c@telia.com>
Date: Mon, 5 Jun 2017 16:19:55 +0200
Message-ID: <CADqTB_hNob7ZiGX66gJEpCymrZJqqsZ1uAGnYg6v6sbrwx1-KQ@mail.gmail.com>
To: =?UTF-8?Q?Bj=C3=B6rn_Larsson?= <bjorn.x.larsson@telia.com>
Cc: Theodore Brown <theodorejb@outlook.com>, Levi Morrison <levim@php.net>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="f403045c67a48471ac05513732b3"
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: rasmus@mindplay.dk (Rasmus Schultz)

--f403045c67a48471ac05513732b3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Of the proposed options, I'd prefer the double fat-arrow =3D=3D>

However, I remain of the opinion that all of those syntaxes are
work-arounds to ambiguity concerns for cases that likely don't actually
occur in real-world codebases.

I don't understand the motivation to design or optimize based on some
theoretical concerns - I'd strongly prefer we do the obvious thing, which,
as I see it, would be to do what most languages do, e.g. the familiar fat
arrow =3D> syntax.

If we're going to provide a closure feature that works more like what you'd
typically find in other languages, we should try to also make it look like
it does in most other languages.

It was said of the generics syntax that I proposed that it would have
ambiguity issues, that it would be impossible (or very difficult) to
implement, but someone actually went an implemented it. I'm generally a bit
skeptical of people who cry "impossible" before giving it their best effort=
.

Inventing unfamiliar syntax for familiar features should be a painful last
resort, if there is no other choice.

Just my opinion.

I'd love to have this feature, but I'd prefer we don't introduce anymore
"muck" if it's at all avoidable.


On Mon, Jun 5, 2017 at 3:10 PM, Bj=C3=B6rn Larsson <bjorn.x.larsson@telia.c=
om>
wrote:

> Den 2017-06-01 kl. 18:58, skrev Theodore Brown:
>
> On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote:
>>
>> 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
>>> 5.
>>> [](params) =3D> expr // binds no values
>>> [=3D](params) =3D> expr // binds by value
>>> [&](params) =3D> expr // binds by reference
>>>
>> As a userland developer, I've been waiting/hoping for short arrow
>> functions for a long time!
>>
>> Option 3 seems like the most obvious choice, since that's the
>> same syntax Hack uses. Would it be very difficult to implement the
>> parser changes necessary for this syntax? Or is there some other
>> downside to a more powerful grammar/parser (e.g. worse performance)?
>>
>> If option 3 isn't viable, my next preference would be option 1.
>> Presumably the drawback of a new symbol is that it might break
>> existing code using `fn` as the name of a class or function.
>> However, using a new symbol would arguably enable more readable
>> code than the other options.
>>
>> Option 2 is not only lengthy, but it also could be confusing
>> since it reuses the `function` symbol for something that isn't
>> a normal function.
>>
>> Option 5 seems overly complex and hard to read.
>>
>> Whether option 1, 2, or 3 is used, to me it seems that capturing by
>> reference would be the most useful and intuitive behavior. It's
>> intuitive since implicit capture makes it feel like all the captured
>> variables are in the same scope.
>>
>
> As a user land developer, option 3 is also my favourite followed by 5 and
> last 1.
>
> However, for option 5 I would prefer =3D=3D> syntax and for option 1 I wo=
uld
> prefer
> lambda as a keyword instead of fn.
>
> One thought that struck me, would option 3 be possible to extend also
> including
> option 5 either as a voting option or in a future RFC?
>
> And yes, arrow functions is much welcome!
>
> r//Bj=C3=B6rn
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--f403045c67a48471ac05513732b3--