Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117905
Message-ID: <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
Date: Sat, 11 Jun 2022 22:14:28 +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>
In-Reply-To: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@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 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.


My main concern is summed up accidentally by your choice of subject line 
for this thread: is the proposal to add *short closure syntax* or is it 
to add *auto-capturing closures*?

They may sound like the same thing, but to me "short closure syntax" 
(and a lot of the current RFC) implies that the new syntax is better for 
nearly all closures, and that once it is introduced, the old syntax 
would only really be there for compatibility - similar to how the [] 
syntax replaces array() and list(). If that is the aim, it's not enough 
to assert that "the majority" of closures are very short; the syntax 
should stand up even when used for, say, a middleware handler in a 
micro-framework. As such, I think we need additional features to opt 
back out of capturing, and explicitly mark function- or block-scoped 
variables.

On the other hand, "auto-capturing" could be seen as a feature in its 
own right; something that users will opt into when it makes sense, while 
continuing to use explicit capture in others. If that is the aim, the 
proposed syntax is decidedly sub-optimal: to a new user, there is no 
obvious reason why "fn" and "function" should imply different semantics, 
or which one is which. A dedicated syntax such as use(*) or use(...) 
would be much clearer. We could even separately propose that "fn" and 
"function" be interchangeable everywhere, allowing combinations such as 
"fn() use(...) { return $x; }" and "function() => $x;"


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.

This is also where comparison to other languages falls down: most 
languages which capture implicitly for closures also merge scopes 
implicitly at other times - e.g. global variables in functions; instance 
properties in methods; or nested block scopes. Generally they also have 
a way to opt out of those, and mark a variable as local to a function or 
block; PHP does not, because it has always required an opt *in*.


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.


Regards,

-- 
Rowan Tommins
[IMSoP]