Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98057
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: internals@lists.php.net
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
Message-ID: <5cfd2ff9-d4b1-e1cc-e4a3-c3b26b9b7fba@gmail.com>
Date: Mon, 30 Jan 2017 23:05:19 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
From: rowan.collins@gmail.com (Rowan Collins)

On 30/01/2017 17:55, Levi Morrison wrote:
> Bob Weinand and I are happy to announce that the [Arrow Functions][1]
> RFC is moving into the public discussion phase. We have been
> collaborating on this RFC for many months now and finally have a
> proposal we are happy to discuss in the open.
>
>    [1]: https://wiki.php.net/rfc/arrow_functions

Firstly, I like this proposal a lot more than the previous, so thank you 
for working on this based on previous discussion. In particular, I'm 
glad to see it focused on single expressions with implicit return, as I 
think that's where it has most value.

A few comments:

> ThisRFC does support type declarations for parameters and return types.

An example of the syntax for this would be good, particularly how the 
return type fits the syntax (which may conflict with my suggestion below).


> The implementation currently supports static closures, for  example |static fn($x) => static::get($x)|.

I was initially confused by this paragraph, because I was unaware that 
static closures existed. I'm still not entirely sure *why* they exist, 
but for anyone else wondering, here's what they currently look like: 
http://php.net/manual/en/functions.anonymous.php#functions.anonymous-functions.static


Finally, my personal preference is still for a syntax that encloses the 
whole definition somehow, and since we need the fn keyword anyway, I 
wonder about stretching the brackets around the whole definition, e.g. 
fn($x => $x * 2).

Personally, I find this:

->reduce(fn($tmp, $v => $tmp + $v), 0)

easier to mentally parse than this:

->reduce(fn($tmp, $v) => $tmp + $v, 0)

because you only have to match brackets to see where the ", 0" belongs.


I also think it would make combining closures clearer if they were 
nested rather than associative (I guess those used to reading Haskell 
will probably disagree with me):

$complement = fn($f) => fn(... $args) => !$f(... $args)

vs

$complement = fn($f => fn(... $args => !$f(... $args)))


Regards,

-- 
Rowan Collins
[IMSoP]