[RFC] Arrow Functions

I messaged the list about this feature before I had the RFC written up
for it. The RFC1 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.

--

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

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

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/

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

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