On Tue, May 30, 2017 at 12:36 PM, Nikita Popov <nikita....@gmail.com> wrote: > On Tue, May 30, 2017 at 8:24 PM, Levi Morrison <le...@php.net> wrote: >> >> On Tue, May 30, 2017 at 12:16 PM, Björn Larsson >> <bjorn.x.lars...@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
As already mentioned we must maintain a leading `=` or `&`: [=, $var1, $var2]() [=, $var1, $var2]() Sorry if that was unclear. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
