Of the proposed options, I'd prefer the double fat-arrow ==> However, I remain of the opinion that all of those syntaxes are work-arounds to ambiguity concerns for cases that likely don't actually occur in real-world codebases.
I don't understand the motivation to design or optimize based on some theoretical concerns - I'd strongly prefer we do the obvious thing, which, as I see it, would be to do what most languages do, e.g. the familiar fat arrow => syntax. If we're going to provide a closure feature that works more like what you'd typically find in other languages, we should try to also make it look like it does in most other languages. It was said of the generics syntax that I proposed that it would have ambiguity issues, that it would be impossible (or very difficult) to implement, but someone actually went an implemented it. I'm generally a bit skeptical of people who cry "impossible" before giving it their best effort. Inventing unfamiliar syntax for familiar features should be a painful last resort, if there is no other choice. Just my opinion. I'd love to have this feature, but I'd prefer we don't introduce anymore "muck" if it's at all avoidable. On Mon, Jun 5, 2017 at 3:10 PM, Björn Larsson <bjorn.x.lars...@telia.com> wrote: > Den 2017-06-01 kl. 18:58, skrev Theodore Brown: > > On Tuesday, May 30, 2017 at 12:58 PM, Levi Morrison wrote: >> >> Based on the discussion there are a few different syntax choices >>> people liked. Overall it's a feature that people seem to want but >>> everyone seems to prefer a different syntax choice. >>> >>> 1. fn(params) => expr >>> 2. function(params) => expr >>> 3. (params) ==> expr >>> 4. (params) => expr >>> 5. >>> [](params) => expr // binds no values >>> [=](params) => expr // binds by value >>> [&](params) => expr // binds by reference >>> >> As a userland developer, I've been waiting/hoping for short arrow >> functions for a long time! >> >> Option 3 seems like the most obvious choice, since that's the >> same syntax Hack uses. Would it be very difficult to implement the >> parser changes necessary for this syntax? Or is there some other >> downside to a more powerful grammar/parser (e.g. worse performance)? >> >> If option 3 isn't viable, my next preference would be option 1. >> Presumably the drawback of a new symbol is that it might break >> existing code using `fn` as the name of a class or function. >> However, using a new symbol would arguably enable more readable >> code than the other options. >> >> Option 2 is not only lengthy, but it also could be confusing >> since it reuses the `function` symbol for something that isn't >> a normal function. >> >> Option 5 seems overly complex and hard to read. >> >> Whether option 1, 2, or 3 is used, to me it seems that capturing by >> reference would be the most useful and intuitive behavior. It's >> intuitive since implicit capture makes it feel like all the captured >> variables are in the same scope. >> > > As a user land developer, option 3 is also my favourite followed by 5 and > last 1. > > However, for option 5 I would prefer ==> syntax and for option 1 I would > prefer > lambda as a keyword instead of fn. > > One thought that struck me, would option 3 be possible to extend also > including > option 5 either as a voting option or in a future RFC? > > And yes, arrow functions is much welcome! > > r//Björn > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
