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". 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? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
