Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88539
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NrsKR3etBoUAz2aAK1HmJToqgK5=rRMRaA3xH8RHtwYAA@mail.gmail.com>
References: <CAFMT4NrOsRm_6Qb11cbtsq0H-_OYugu-u-3Q+EC9J3Ze9BNAYg@mail.gmail.com>
	<CAB6YZuxQDPS8V67vof7wmg7oh1dv5dseNX5Uq5J=iUBYGWt7=Q@mail.gmail.com>
	<CAFMT4NrsKR3etBoUAz2aAK1HmJToqgK5=rRMRaA3xH8RHtwYAA@mail.gmail.com>
Date: Tue, 29 Sep 2015 08:23:19 +0200
Message-ID: <CAB6YZuzhR4Ep3gM-k=TH5bhDsTRmyfF3xOq+NjTfQo0dTOA3MA@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Arrow function expressions in PHP
From: pajousek@gmail.com (=?UTF-8?Q?Pavel_Kou=C5=99il?=)

On Tue, Sep 29, 2015 at 12:52 AM, Levi Morrison <levim@php.net> wrote:
>
> I do not think it is feasible to make the parser do backtracking or
> anything of that sort. How do others feel?
>
>> PS: the [fn($x) => $x * 2] seems ambigous, from reader's POV; key of
>> the item is result of fn($x) and value is $x * 2? Also, it would be a
>> huge BC break with not allowing you to name functions fn(), wouldn't
>> it?
>
> This is not a huge backwards compatibility break, no. It is a small
> break. This is one reason `fn` is not necessarily what I will be
> proposing and want to hear more feedback. Note that the `function`
> version wouldn't be possible to be confused *at all*:
>
>     // function($x) isn't allowed for function name
>     // so this is very unambiguous
>     [function($x) => $x * 2];
>
> Also note that using closures in array literals is not really that common.

When you choose the function($x) ~> $x * 2 (or with ==> or =>
operator), you end up saving around 5 or 6 characters from the "long
declaration", ending up with "not-so-short closures" instead. You save
a little bit more if you have the implicit "use", but that's one thing
people are torn about, by looking at the discussion about the RFC, but
I think it's too long, for "short closures".

Would making the parser do some backtracking be really that bad -
especially since the option would end up with the IMHO most convenient
option for actual users of the feature?