Den 2017-05-30 kl. 20:24, skrev Levi Morrison:
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.
Ok, but how about having ==> to improve readability and make it
less ambiguous & quicker to read the code. Also enable the syntax:
- (params) ==> expr // binds no values.
r//Björn
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
