Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:99600
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.128.175 as permitted sender)
References: <CAFMT4Npoo_ZrRk-kk4C6KHYEtV93pU7Wmh0FhaPi6Z-9qkObaQ@mail.gmail.com>
 <b47c4379-109c-c289-1077-b42ea40fe19f@telia.com>
 <ca6f11d0-5da3-757c-7acd-4acd79a876f1@fleshgrinder.com>
 <5fe1eefe-1c4f-4c31-c975-ab6c768c977c@telia.com>
 <E56D1F4A-6DC7-47DA-BAD6-1722E017B048@me.com>
 <CADqTB_jDmFZZc3ah=J8F99P77qnuWVgXS5UwXgrbartCp5B+UQ@mail.gmail.com>
 <3C763609-54FC-480B-AE95-94A1873226E0@me.com>
 <CADqTB_hU+38TOHdaukhGBS-2NPq-PNSci1h078TPOGbE7WcmWg@mail.gmail.com>
 <9A3447BF-F982-4C5A-B55B-466036AF2E53@me.com>
 <CAFMT4NrdCRJxGyeGqLbAoaV896FN6VpDjY-68trXoaRgZe4VyQ@mail.gmail.com>
 <CADqTB_hT-Nd5wX129GgeQxL8RNJ85maSPOPHUt-2NK-ef3yF-g@mail.gmail.com>
 <CADqTB_hB1ifmXu4VO6Z4A3gN=2AF_PU4C8yCYXz8QN6zZ_k=6w@mail.gmail.com>
 <2d89daaa-056f-3dcb-a5f2-b790affe203a@garfieldtech.com>
 <CADqTB_gN+bdU9HBbyjpJJCK7FxO_rQi9hmEuhANGEkc52mpHtw@mail.gmail.com>
 <DC4F8FEC-7EAA-4D14-BD57-C48DC0A7D392@gmail.com>
 <CADqTB_jXUtjVMexZOScHN96sQYgLKdws6_rGCWV8MDriSe4hCQ@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Message-ID: <76f05ddb-fe72-fa90-e3a0-8e5233952aa1@gmail.com>
Date: Wed, 21 Jun 2017 22:19:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <CADqTB_jXUtjVMexZOScHN96sQYgLKdws6_rGCWV8MDriSe4hCQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions
From: rowan.collins@gmail.com (Rowan Collins)

On 21/06/2017 15:04, Rasmus Schultz wrote:
 > > For me (and I am not alone), this feature is NOT a new syntax for 
closures
 >
 > Regardless of why you want it, that's exactly what it is though - 
another way to declare a closure.
 >
 > Even if it has different semantics, the resulting object is still an 
instance of Closure, right?
 >
 > It should pass type-checks, it should support reflection, and so on - 
otherwise, that's even more inconsistency,
 > for no practical reason, and it will lead to an endless list of 
problems which people will solve with even more ugly work-arounds,
 > such as omitting type-hints, etc.

I am perfectly happy for the feature to support all those things.


 > > If what you are looking for is a replacement syntax for existing 
closures, you will have a completely different set of priorities
 >
 > I am not looking for a replacement syntax, but rather a replacement 
feature.

Then you are looking for something different from me. Again, I don't say 
you are wrong in this, I just don't share that desire, because I don't 
see the need to replace - or supplement - a working feature with a 
slightly different version.


 > I think the priorities and requirements remain the same, but for 
consistency, and to keep this feature generally useful,
 > this feature should have parity with current Closures in terms of 
capabilities - otherwise it will get in the way rather than help.

Again, this makes sense only given your starting point, which is not the 
same as mine.


 > Once people see the nicer, shorter syntax, and start to enjoy the 
more natural scoping rules, it's going to be
 > very frustrating to have to back-port to the old function-syntax and 
add use-clauses etc every time the code
 > changes and a single expression doesn't cut it.

I mentioned this in my last e-mail without going into details, because 
it was discussed at length in the past, but perhaps you missed that, or 
have forgotten. In PHP, automatic capture of variables is absolutely not 
a natural scoping rule. Apart from the request super-globals - which 
many modern frameworks deliberately hide away from the user - every 
single variable has to be explicitly declared or imported into every 
single scope, throughout the entire language.

The "use" clause on anonymous functions is not some weird wart for 
implementation purposes, it is the natural companion to the "global" and 
"static" keywords, and the natural consequence of not having a 
declaration to force a variable to be local. In PHP, all variables are 
local to a function by default, unless something explicitly says 
otherwise; there are certainly languages, notably JS, where the opposite 
is true, but that doesn't mean PHP is doing it wrong, or that mixing the 
two conventions in one language would be a good idea.

I am willing to accept single-expression lambdas as an exception to this 
rule only because they are constrained to be short and simple; they read 
like an expression embedded in the outer scope, not a complete function 
in their own right.


 > A single-expression constraint on this feature would be a strange, 
arbitrary, annoying, unnecessary limitation.
 >
 > We didn't get it right the first time.

I disagree with both of these statements. I don't consider this feature 
an attempt to fix something that went wrong, I consider it a new, 
complimentary, feature, for certain cases. Personally, I could live 
without it, but I have been convinced that it would be a useful 
short-hand for certain coding patterns.


If we were to allow multiple-statement automatic-capturing closures, we 
would end up with 3 different ways to declare the same thing; using the 
fn() variant as an example:

function($x) use($y) { return $x * $y; } // Long form; explicit return 
and explicit capture
fn($x) => $x * $y; // Short form; implicit return and implicit capture
fn($x) => { return $x * $y; } // Hybrid; explicit return, but implicit 
capture

The short form is still constrained to be a single expression, because 
otherwise you can't omit the "return" statement; we would just have a 
third form that looks a bit like the short form, but isn't. So whatever 
syntax we choose, you won't be able to just add a semicolon and an extra 
line to turn a lambda expression into a function body.

To me, the hybrid form is confusing and redundant; the fully shortened 
form makes certain simple closures considerably more concise, and 
remains reasonably readable. It is sugar for those use cases, just as 
the closure itself could be considered sugar for constructing an 
invokable object with private fields, and just as many other language 
features are sugar for more basic operations.

Regards,
-- 
Rowan Collins
[IMSoP]