Den 2017-05-31 kl. 00:26, skrev Levi Morrison:
On Tue, May 30, 2017 at 3:37 PM, Björn Larsson
<bjorn.x.lars...@telia.com> wrote:
Den 2017-05-30 kl. 21:40, skrev Derick Rethans:
On Tue, 30 May 2017, Levi Morrison wrote:
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?
I think 5 is terrible from a readability point of view. As you said it:
"symbol soup".
Do you think having ==> instead of => would make it less of a
symbolic soup?
If something is already symbol soup how does adding another symbol
make it less so?
For me it was about using a symbol that is not used for
other things like arrays. Kind of a new ingredience to the
soup ;-)
Not sure at all about the syntax, but going from Sara's
example earlier.
1. [[]($x)=> $x] a bit similar to [($x)=> $x]
vs
2. [[]($x)==> $x] less similar to [($x)=> $x]
2 has in my eyes less soup factor...
Cheers //Björn
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
