Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117908
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-ID: <d568ea21-0378-4ad5-81c4-862a1148a327@www.fastmail.com>
In-Reply-To: <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
Date: Sat, 11 Jun 2022 21:01:29 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Jun 11, 2022, at 4:14 PM, Rowan Tommins wrote:
> On 09/06/2022 17:34, Larry Garfield wrote:
>> Last year, Nuno Maduro and I put together an RFC for combining the multi-line capabilities of long-closures with the auto-capture compactness of short-closures ... Arnaud Le Blanc has now picked up the flag with an improved implementation ... The RFC has therefore been overhauled accordingly and is now ready for consideration.
>>
>> https://wiki.php.net/rfc/auto-capture-closure
>
>
> First of all, thanks to all three of you for the work on this. Although 
> I'm not quite convinced yet, I know a lot of people have expressed 
> desire for this feature over the years.

> To go back to the point about variable scope: right now, if you're in a 
> function, all variables are scoped to that function. With a tiny handful 
> of exceptions (e.g. superglobals), access to variables from any other 
> scope is always explicit - via parameters, "global", "use", "$this", and 
> so on. If we think that should change, we should make that decision 
> explicitly, not treat it as a side-effect of syntax.
>
> I don't find the comparison to a foreach loop very convincing. Loops are 
> still only accessing variables while the function is running, not saving 
> them to be used at some indeterminate later time. And 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.  PHP is not one of them, but to someone coming from a language that does, PHP's way of doing things is just as weird and requires learning.  The point here is that "which things create a scope and which don't" are not "intuitive" in any language.  They're always language-idiomatic, and may or may not be internally consistent, which is the important part.

PHP is fairly internally consistent: functions and classes create a scope, nothing else does.  This RFC doesn't change that one way or another, so it's not really any harder to learn.  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.

> Which leads me back to my constructive suggestion: let's introduce a 
> block scoping syntax (e.g. "let $foo;") as a useful feature in its own 
> right, before we introduce short closures.
>
> As proposed, users will need to have some idea of what "live variable 
> analysis" means, or add dummy assignments, if they want to be sure a 
> variable is actually local. With a block scoping keyword, they can mark 
> local variables explicitly, as they would in other languages.

That may be a useful feature on its own, especially for longer loops.  I'm definitely open to discussing that.  I don't think that is a prerequisite for a nicer lambda syntax, however, as I don't think the confusion potential is anywhere near as large as you apparently fear it is.

--Larry Garfield