Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:88678
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.180 as permitted sender)
To: internals@lists.php.net
References: <CAFMT4Nq2Ki-yXAe8BqX35=+qg=2xO3VVUL=Ss01BO=Y6WTnk3A@mail.gmail.com>
 <56103B9F.7080508@thefsb.org>
Message-ID: <561259A3.9080908@gmail.com>
Date: Mon, 5 Oct 2015 12:06:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <56103B9F.7080508@thefsb.org>
Content-Type: multipart/alternative;
 boundary="------------080904000806080903000203"
Subject: Re: [PHP-DEV] Re: [RFC] Arrow Functions
From: rowan.collins@gmail.com (Rowan Collins)

--------------080904000806080903000203
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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)




--------------080904000806080903000203--