Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98083
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.25 cause and error)
To: internals@lists.php.net
References: <CAFMT4Nrt7XPMnELoAGLu=sSRCTCtzPCTaSE8HJjKfHjDXOXU_A@mail.gmail.com>
 <E6.ED.51557.B64EF885@pb1.pair.com>
 <3F428CA4-8211-44E6-9B60-62ADB47934B3@koalephant.com>
 <642a72cd-e322-0b22-452f-dfbd521aee02@php.net>
 <BLU436-SMTP4506E841E18C53E37A3CF4E24A0@phx.gbl>
Message-ID: <37679ae0-eb90-2367-7fc0-8f0adf97a965@garfieldtech.com>
Date: Tue, 31 Jan 2017 11:29:32 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP4506E841E18C53E37A3CF4E24A0@phx.gbl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC][Discuss] Arrow Functions
From: larry@garfieldtech.com (Larry Garfield)

On 01/31/2017 05:14 AM, Bob Weinand wrote:
>>
>>> In the case that regular closures got auto-capture, would a
>>> `use($foo, $bar, $baz)` segment on a closure still be honoured (i.e.
>>> disable auto-capture), and would it have any impact (positive or
>>> negative) on performance/memory usage? After several years of JS
>>> closure ‘fun’ I kind of like that with PHP you only inherit the
>>> variables you explicitly `use()` in closures.
>> Wouldn't there be just too many existing closures, which do not use
>> `use` but (maybe) expect a clean scope?
>
> The RFC is exclusively proposing single-expression short Closures.
> We do NOT want multi-statement short Closures; it is a *feature* that generic Closures need an "use ($foo, $bar)".
> This vastly improves readability and debuggability - it basically tells you whether the variables inside the code are imported or not. As Stephen Reay notes:
>>> After several years of JS
>>> closure ‘fun’ I kind of like that with PHP you only inherit the
>>> variables you explicitly `use()` in closures.
>
> So, auto-import for generic Closures definitely isn't an option.
> Just on short, single-line Closures there is no benefit to "use ()", as EVERY variable used in the short Closure is supposed to be an imported variable. There is no point in forcing the user to distinguish between imported and local variable here.
>
> Also, using "fn" in favor of "function" has the advantage of less clutter in one line. Compare
>
> array_map(fn($x) => $x + 1)
>
> to
>
> array_map(function($x) => $x + 1)
>
> The syntactical construction is already pretty clearly showing what's going on. The "function" keyword itself is already larger than the whole body. It distracts while reading the actual code.
> Additionally, using "fn" is optically highlighting the fact that it's a short-Closure with auto-import and not a normal Closure with explicit import.
>
> Thanks,
> Bob

I must agree with Bob and the other authors.  The entire point of this 
RFC is to reduce the amount of typing, and therefore reading, that goes 
into using simple closures as first-class values.  Using longer keywords 
instead of shorter ones is counter to that aim.  It sounds like the 
earlier proposal of keyword-less closures isn't technically feasible or 
it would make sense to argue for that.

My question is why there's no mention of HHVM short closures, or the 
previous RFC to take that approach.  See:

https://docs.hhvm.com/hack/lambdas/introduction

If there's a good reason to not use that syntax, OK, but that should be 
stated explicitly in the RFC with links to both HHVM and to the previous 
short-closure RFC.

I also echo the previous call to clarify with examples how types would 
be used, syntactically.

Since there is no "return" keyword used, that implies that no "yield" 
keyword can be used, either.  That is, arrow-function generators are not 
supported.  Is that correct?  (In context they may not make sense to 
have, but that should be clarified explicitly in the RFC.)

Overall I am +1 on this RFC.

--Larry Garfield