Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99311
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain outlook.com designates 40.92.8.39 as permitted sender)
To: Levi Morrison <levim@php.net>, internals <internals@lists.php.net>
Thread-Topic: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
Thread-Index: AQHS2W5iuE7e5VDar0K3q/rbmtl0haIQItMC
Date: Thu, 1 Jun 2017 16:58:08 +0000
Message-ID: <DM3PR18MB07641E547AD2FA1DFA5BEF65DEF60@DM3PR18MB0764.namprd18.prod.outlook.com>
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
In-Reply-To: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [9E2LW/Ml2ywlk89SQPXucUWkMA9m4Sxu8feFjKjFJr0=]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1;DM3NAM03HT187;24:5AMfdNoi9P9xIQKwiEB4I+P2NjnIp9DlBl3tWiVaQScovmigHfSgXVVuX/Z5Nu3PPuxAz+NKERQUTFsTXcotcTIY8zQaupfBU0W2g98JdZU=;7:73PTOSqVAQ2BzMNk7c6Ua4ioisfISQ32rSWluiGROlReKaW5sectwJq4sNtOHRNzmfXthMvt2QNQHxHHb7Pgs+zCq4A8Y2SaxTBQDhCX/7tVV//B3Si2YPSvijNyAwGL12jpHDi6I1LBHQ7zI5x3WKeX4P63FW2FSdZW08rmzHwrt0CqgmhsZQ/wsz/DDfCUC5t+rcLruGC25KI/JZXQ2SdTQdsmfXMHxcaAnZ76iyJp6yTteTLnpQppuEPznOYUectw2yezG2QsHNHBlugenmIfMrLvEZQUlHm6hBzjsOgVh3gBhi38+0A5g61g8wJC
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(7070007)(98901004);DIR:OUT;SFP:1901;SCL:1;SRVR:DM3NAM03HT187;H:DM3PR18MB0764.namprd18.prod.outlook.com;FPR:;SPF:None;LANG:en;
x-ms-traffictypediagnostic: DM3NAM03HT187:
x-ms-office365-filtering-correlation-id: 89f7da56-238c-4aa3-7d56-08d4a90f6166
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322274)(1601125374)(1603101448)(1701031045);SRVR:DM3NAM03HT187;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031);SRVR:DM3NAM03HT187;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DM3NAM03HT187;
x-forefront-prvs: 0325F6C77B
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jun 2017 16:58:08.8386
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM3NAM03HT187
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: theodorejb@outlook.com (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.=