# [RFC] Arrow Functions

- Thread: https://externals.io/message/88651
- Original archive: https://news-web.php.net/php.internals/88651
- Started by Levi Morrison on 2015-10-02T23:17:19+00:00
- Messages: 7
- RFC: Arrow Functions (Obsolete) — https://externals.io/rfc/arrow_functions.md
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · RFCs at https://externals.io/rfc.md · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #88651 — Levi Morrison — 2015-10-02T23:17:19+00:00

URL: https://externals.io/message/88651#88651

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

---

## #88652 — pajousek@gmail.com — 2015-10-03T08:06:42+00:00

URL: https://externals.io/message/88651#88652 · In reply to: #88651

> 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
>
> --
> 
> 
>

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

---

## #88653 — Thomas Bley — 2015-10-03T14:38:52+00:00

URL: https://externals.io/message/88651#88653 · In reply to: #88652

Pavel Kouřil wrote on 03.10.2015 10:06:

> 
> > […]
> 
> 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
> 
> --
> 
> 
> 

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

---

## #88654 — Tom Worster — 2015-10-03T20:33:35+00:00

URL: https://externals.io/message/88651#88654 · In reply to: #88651

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

---

## #88661 — Andrea Faulds — 2015-10-04T10:34:58+00:00

URL: https://externals.io/message/88651#88661 · In reply to: #88651

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/

---

## #88678 — Rowan Collins — 2015-10-05T11:06:11+00:00

URL: https://externals.io/message/88651#88678 · In reply to: #88654

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)

---

## #88836 — bjorn.x.larsson@telia.com — 2015-10-15T19:50:00+00:00

URL: https://externals.io/message/88651#88836 · In reply to: #88651

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