Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] Arrow Functions »

[RFC] Arrow Functions

php.internals

Levi Morrison

10 years ago
I messaged the list about this feature before I had the RFC written up for it. The RFC[1] is slightly different from what I proposed in the previous thread, so please read the RFC to make sure you understand what is being proposed before replying here. Here's a small example: $y = 10; $result = array_map(function($x) => $x + $y, [1, 2, 3]); // $result is [11, 12, 13] Thanks for people who have participated in conversation so far, as well as those who participated in Bob's short closures proposal as well. [1]: https://wiki.php.net/rfc/arrow_functions

Pavel Kouřil

10 years ago
On Sat, Oct 3, 2015 at 1:17 AM, Levi Morrison <morrison.levi@gmail.com> wrote:
> I messaged the list about this feature before I had the RFC written up > for it. The RFC[1] is slightly different from what I proposed in the > previous thread, so please read the RFC to make sure you understand > what is being proposed before replying here. > > Here's a small example: > > $y = 10; > $result = array_map(function($x) => $x + $y, [1, 2, 3]); > > // $result is [11, 12, 13] > > Thanks for people who have participated in conversation so far, as > well as those who participated in Bob's short closures proposal as > well. > > [1]: https://wiki.php.net/rfc/arrow_functions > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
Hello, thanks for another proposal on this feature. :) As I said in the previous e-mails, I'm not really fan of the "function" prefix - because it has the same prefix as the "long declarations". Just by removing the { } for =>, the autobinding also goes into place* and also only one expression is allowed, but the "beggining" stays the same (that being function ($x)). The function keyword also "collides" with the future scope with multiple statements. function ($x) use ($a, $b, $c) { $z = foo($a, $b); return $c($z, $x); } function ($x) => { $z = foo($a, $b); return $c($z, $x); } Now the possible confussion with the different scoping rules would be even bigger, IMHO. (Disclaimer: I am huge fan of those autoimports and think that without them, the RFC doesn't technically bring anything important.) Also, I'm not a fan of the "fn" prefix, because then you would have two ways of writing "function", and people would probably want being able to use "fn" for named functions as well, bringing inconsistency into language. Also, this would requiring making "fn" a reserved word, breaking some applications - wouldn't it? Personally I'd prefer the \ prefix you also mention as possible in your RFC. It's also AFAIK used to denote lamba expression in another languages already, so it might be familiar for some developers? \(int $x) => $x * $y; \() => foo() \($x) => \($y) => \($z) Yeah, this looks pretty nice. Althought I'd honestly really prefer the Bob's syntax, but I understand that you don't want to make some engine hacks to make it working - but from userland developer's POV, that one was the best (speaking as someone, who would use the syntax daily).
-- Regards Pavel Kouřil

Unnamed Person

10 years ago
Pavel Kouřil wrote on 03.10.2015 10:06:
> On Sat, Oct 3, 2015 at 1:17 AM, Levi Morrison <morrison.levi@gmail.com> wrote: >> I messaged the list about this feature before I had the RFC written up >> for it. The RFC[1] is slightly different from what I proposed in the >> previous thread, so please read the RFC to make sure you understand >> what is being proposed before replying here. >> >> Here's a small example: >> >> $y = 10; >> $result = array_map(function($x) => $x + $y, [1, 2, 3]); >> >> // $result is [11, 12, 13] >> >> Thanks for people who have participated in conversation so far, as >> well as those who participated in Bob's short closures proposal as >> well. >> >> [1]: https://wiki.php.net/rfc/arrow_functions >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: http://www.php.net/unsub.php >> > > Hello, > > thanks for another proposal on this feature. :) > > As I said in the previous e-mails, I'm not really fan of the > "function" prefix - because it has the same prefix as the "long > declarations". Just by removing the { } for =>, the autobinding also > goes into place* and also only one expression is allowed, but the > "beggining" stays the same (that being function ($x)). > > The function keyword also "collides" with the future scope with > multiple statements. > > function ($x) use ($a, $b, $c) { $z = foo($a, $b); return $c($z, $x); } > function ($x) => { $z = foo($a, $b); return $c($z, $x); } > > Now the possible confussion with the different scoping rules would be > even bigger, IMHO. (Disclaimer: I am huge fan of those autoimports and > think that without them, the RFC doesn't technically bring anything > important.) > > Also, I'm not a fan of the "fn" prefix, because then you would have > two ways of writing "function", and people would probably want being > able to use "fn" for named functions as well, bringing inconsistency > into language. Also, this would requiring making "fn" a reserved word, > breaking some applications - wouldn't it? > > Personally I'd prefer the \ prefix you also mention as possible in > your RFC. It's also AFAIK used to denote lamba expression in another > languages already, so it might be familiar for some developers? > > \(int $x) => $x * $y; > \() => foo() > \($x) => \($y) => \($z) > > Yeah, this looks pretty nice. > > Althought I'd honestly really prefer the Bob's syntax, but I > understand that you don't want to make some engine hacks to make it > working - but from userland developer's POV, that one was the best > (speaking as someone, who would use the syntax daily). > > -- > > Regards > Pavel Kouřil > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php >
I would prefer to keep the current syntax and just a different keyword for autobindung: function ($x) use ($a, $b, $c) { $z = foo($a, $b); return $c($z, $x); } function ($x) autobind|autouse|use_all|autoimport|etc. { $z = foo($a, $b); return $c($z, $x); } Regards Thomas

Tom Worster

10 years ago
when the grammar starts with function(args), it seems the main difference from existing grammar is to make the curly braces when there's only one statement in the function block. in other contexts i had the impression that things like if (bool-expr) statement; and similar were going out of fashion fast. tom

Rowan Collins

10 years ago
Tom Worster wrote on 03/10/2015 21:33:
> when the grammar starts with function(args), it seems the main > difference from existing grammar is to make the curly braces when > there's only one statement in the function block. > > in other contexts i had the impression that things like > > if (bool-expr) statement; > > and similar were going out of fashion fast.
Yeah, I'm not sure I agree with this line in the RFC at all:
> It also avoids the use of |{}| which means that writing closures
in-line is less painful. Avoiding the *return* statement I'm right behind, but if the => is no longer acting like an operator (which with the function keyword in place, it's really not), some extra brackets around the expression seem like they'd improve readability. What about moving the => into the function(...) block? function($foo) => $x * $y vs function($foo => $x * $y)

Andrew Faulds

10 years ago
Hey Levi, Levi Morrison wrote:
> I messaged the list about this feature before I had the RFC written up > for it. The RFC[1] is slightly different from what I proposed in the > previous thread, so please read the RFC to make sure you understand > what is being proposed before replying here. > > Here's a small example: > > $y = 10; > $result = array_map(function($x) => $x + $y, [1, 2, 3]); > > // $result is [11, 12, 13]
As I've said elsewhere, I quite like this syntax. There's no weird new operator to learn, for starters. The use of the existing keyword means it's more obvious to unfamiliar PHP users what it is, and it's "Googleable". Yet the syntax is still significantly less verbose than before, so it's still helpful. I'd particularly like it if we could use this syntax for methods, as has been suggested under future scope. It'd slim down "getter" methods quite a bit. Do you think you could do that as a separate vote within the RFC, alongside the main one? That makes it easier for it to get in than having to create a wholly separate RFC for something that's quite a small change. Thanks!
-- Andrea Faulds http://ajf.me/

Björn Larsson

10 years ago
Den 2015-10-03 kl. 01:17, skrev Levi Morrison:
> I messaged the list about this feature before I had the RFC written up > for it. The RFC[1] is slightly different from what I proposed in the > previous thread, so please read the RFC to make sure you understand > what is being proposed before replying here. > > Here's a small example: > > $y = 10; > $result = array_map(function($x) => $x + $y, [1, 2, 3]); > > // $result is [11, 12, 13] > > Thanks for people who have participated in conversation so far, as > well as those who participated in Bob's short closures proposal as > well. > > [1]: https://wiki.php.net/rfc/arrow_functions >
Well my comments are: - By having => as operator we block future idea to remove function keyword in case limitation in parser is overcome. - Also suppose one would like to do a simple grep for all anonymous function in a project, having same as array key will require regexp search. - It would also be good is this RFC includes all required text instead referring to Bob's old one. - I also misses if default values are supported. - Not being able to overcome limitation is parser, seems like this RFC is a compromise for some developers... - For me as a userland developer I prefer Bob's old proposal but with added type hints, default values and requiring parenthesis for the single parameter case. r//Björn