Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88567
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.49 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAB6YZuzhR4Ep3gM-k=TH5bhDsTRmyfF3xOq+NjTfQo0dTOA3MA@mail.gmail.com>
References: <CAFMT4NrOsRm_6Qb11cbtsq0H-_OYugu-u-3Q+EC9J3Ze9BNAYg@mail.gmail.com>
	<CAB6YZuxQDPS8V67vof7wmg7oh1dv5dseNX5Uq5J=iUBYGWt7=Q@mail.gmail.com>
	<CAFMT4NrsKR3etBoUAz2aAK1HmJToqgK5=rRMRaA3xH8RHtwYAA@mail.gmail.com>
	<CAB6YZuzhR4Ep3gM-k=TH5bhDsTRmyfF3xOq+NjTfQo0dTOA3MA@mail.gmail.com>
Date: Tue, 29 Sep 2015 15:55:56 -0600
Message-ID: <CAFMT4Nqq+KXCGde6FBa_jZ0ZjPjdRU7PU2ANCR6V_+SNH2aP+w@mail.gmail.com>
To: =?UTF-8?Q?Pavel_Kou=C5=99il?= <pajousek@gmail.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Arrow function expressions in PHP
From: levim@php.net (Levi Morrison)

On Tue, Sep 29, 2015 at 12:23 AM, Pavel Kou=C5=99il <pajousek@gmail.com> wr=
ote:
> 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) =3D> $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) =3D> $x * 2];
>>
>> Also note that using closures in array literals is not really that commo=
n.
>
> When you choose the function($x) ~> $x * 2 (or with =3D=3D> or =3D>
> 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".

Reading over the list I don't think people "are torn about" it. There
are some detractors, sure, but there seem to be more detractors about
symbol choice (~) and lack of type declarations.

> 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?

I disagree that `(int $x) =3D> $x * 2` is vastly better than `fn (int
$x) =3D> $x * 2`. It *might* be better but so much better we should
introduce backtracking into it? In my opinion that is very clear: no.
Especially because this also makes it harder to write other tools for
PHP.