Re: [RFC]Discuss] Syntax for Arrow Functions

On Tue, May 30, 2017 at 8:24 PM, Levi Morrison <levim@php.net> wrote: > On Tue, May 30, 2017 at 12:16 PM, Björn Larsson > <bjorn.x.larsson@telia.com> wrote: > > Den 2017-05-30 kl. 19:58, skrev Levi Morrison: > >> > >> Internals, > >> > >> The previous discussion thread has died down significantly and so I'd > >> like to start a new one to refocus. This message has some redundant > >> information by design so people don't have to reference the other > >> thread so much. > >> > >> 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 > >> > >> Note that 3 and 4 require a more powerful grammar and parser and that > >> 4 has ambiguities. I think we can work around them by rules -- only > >> mentioning it because its popular because of JavaScript and do not > >> prefer this at all. > >> > >> Note that 1 requires a new keyword. > >> > >> Option 2 looks the best from that perspective but is by far the > >> longest; remember people are partially interested in this feature > >> because they want shorter closures which this doesn't really help. > >> > >> This is why everyone is so divisive. All options have drawbacks. > >> Additionally some people don't like binding by value and would prefer > >> ref, and others really would be against by-ref. > >> > >> Which brings me to an option I don't think was ever discussed on list: > >> > >> 5. > >> [](params) => expr // binds no values > >> [=](params) => expr // binds by value > >> [&](params) => expr // binds by reference > >> > >> It has quite a few good qualities: > >> > >> - No new keywords > >> - Can choose between reference and value > >> - Concise > >> - Has precedence in C++, a major language > >> - Can be done in our existing grammar and parser[1] > >> - Can be extended to allow explicit binding of variables: > >> // all equivalent > >> // y is bound by value, array by reference > >> [&, $y]($x) => $array[] = $x + $y > >> [=, &$array]($x) => $array[] = $x + $y > >> > >> And of course it does have downsides: > >> > >> - Symbol soup (it uses a lot of symbols) > >> - A minor BC break. Empty arrays which are invoked as functions are > >> currently guaranteed to be errors at runtime and would have a new > >> valid meaning. Here's an example from inside an array literal: > >> > >> // error at runtime previously > >> [ []($x) => $x ] > >> // now an array with one item which is a closure that returns > >> its parameter > >> > >> Sara pointed out that we'd need to keep a leading > >> = or & in the > >> array to disambiguate from our array closure form. > >> > >> Overall I'd prefer 1 or 5. What do you guys think? > >> > >> > >> [1]: I'm pretty sure it can be done but until it's done I can't say > >> so confidently because sometimes there are things lurking in our > >> grammar I forget about. > >> > > As I said in the old thread, option 5 with ==> instead of => might > > be an option. I think that would mitigate the minor BC break. > > > > r//Björn > > The compatibility issue is with [](params) is that it is > currently > an empty array literal that will be invoked; this is guaranteed to be > an error at runtime so it is unlikely to cause much trouble. A > trailing ==> would not help here. > You mentioned ability to explicitly specify binding as a possible extension. However [$var1, $var2]() is not necessarily failing right now, it may be a valid array callable. Nikita