Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117913
Message-ID: <6b563cc9-8f2f-6577-fe1a-b945fc67054e@gmail.com>
Date: Sun, 12 Jun 2022 13:58:43 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-GB
To: internals@lists.php.net
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
 <d568ea21-0378-4ad5-81c4-862a1148a327@www.fastmail.com>
In-Reply-To: <d568ea21-0378-4ad5-81c4-862a1148a327@www.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: rowan.collins@gmail.com (Rowan Tommins)

On 12/06/2022 03:01, Larry Garfield wrote:
>> ... users don't "learn to recognize" that a loop doesn't hide all variables from the parent
>> scope; it would be very peculiar if it did.
> There are languages that do, however.  Some languages have block-scoped variables by default (such as Rust), or partially blocked scoped depending on details.


That's not what the RFC example implies, though; it implies that someone 
might expect $guests and $guestsIds to not be usable *inside* the 
foreach loop, because they were declared *outside* it. I don't know of 
any language where entering a loop creates a completely empty symbol 
table, do you?

Whether or not $guest, having been declared *inside* the loop, is 
visible *after* the loop is a completely different question, and one 
that doesn't apply to closures - the content of the closure hasn't been 
executed yet, so it is inevitably a black box to the code after it.


> PHP is fairly internally consistent: functions and classes create a scope, nothing else does.  This RFC doesn't change that one way or another...


The RFC fundamentally changes the rule that a function always creates a 
new, *empty* scope. Every variable that is not local to that scope has 
to be explicitly imported, one way or another.

Every language I know where scopes do *not* start out empty has keywords 
for marking which variables are definitely local to that block. That's 
why I think a "var" or "let" equivalent is a natural accompaniment to 
changing PHP's rules in this way.


> Plus, as noted, the `fn` keyword becomes consistently the flag saying "auto-capture happens here, FYI", which is already the case as of 7.4.


It's a cute idea, but I don't think "if you miss most of the letters out 
of a word, it means this special thing" is at all memorable. I've never 
heard the syntax added in 7.4 called "fn functions", but I've frequently 
heard it called "arrow functions", because what stands out to people is 
the "=>". The keyword is only there because ($a)=>$b on its own would 
collide with array syntax.

I would much rather see "fn" and "function" become synonyms, so that 
"public fn foo() {}" is a valid method declaration, and "function() => 
$foo" is a valid arrow function.


Regards,

-- 
Rowan Tommins
[IMSoP]