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
