Re: Arrow function expressions in PHP
| From: | Pavel Kouřil | Date: | Tue, 29 Sep 2015 06:23:19 +0000 |
| Subject: | Re: Arrow function expressions in PHP | ||
| References: | 1 2 3 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-88539@lists.php.net to get a copy of this message | ||
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?