On Tue, Sep 29, 2015 at 12:23 AM, Pavel Kouřil <pajou...@gmail.com> wrote: > On Tue, Sep 29, 2015 at 12:52 AM, Levi Morrison <le...@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".
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) => $x * 2` is vastly better than `fn (int $x) => $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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
