Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117934
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-ID: <39470114-2c35-4c71-b8ef-c8d3ce3c3555@www.fastmail.com>
In-Reply-To: <8422e11c-4a3f-9f99-56ce-884491dfe08e@gmail.com>
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
 <2347345.PIDvDuAF1L@arnaud-t490>
 <8422e11c-4a3f-9f99-56ce-884491dfe08e@gmail.com>
Date: Mon, 13 Jun 2022 08:52:37 -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 Mon, Jun 13, 2022, at 8:36 AM, Rowan Tommins wrote:
> On 13/06/2022 13:57, Arnaud Le Blanc wrote:
>> The proposal is to extend the Arrow Functions syntax so that it allows
>> multiple statements.
>
>
> That's one perspective. The other perspective is that the proposal is to 
> extend closure syntax to support automatic capture.

As noted before, this is a distinction without a difference.  The proposed syntax brings in one aspect of short-closures and one aspect of long-closures.  Which you consider it "coming from" as a starting point is, in practice, irrelevant.

> By the way, the current RFC implies you could write this:
>
> fn() use (&$myRef, $a) { $myRef = $a * $b; }
>
> It's clear that $myRef is captured by reference, and $a by value; but 
> what about $b? Is it local to the closure as it would be in a "long" 
> closure, or implicitly captured by value as it would be with no "use" 
> statement?
>
> It might be best for such mixtures to raise an error.

The RFC already covers that.  $b will be auto-captured by value from scope if it exists.  See the "Explicit capture" section and its example.

>> Auto-capture in PHP is by-value. This makes this impossible. It also makes
>> explicit declarations non-necessary and much less useful.
>
>> Live-variable analysis is mentioned in as part of implementation details. It
>> should not be necessary to understand these details to understand the behavior
>> of auto-capture.
>
>
> As noted in my other e-mail, by-value capture can still have side 
> effects, so users may still want to ensure that their code is free of 
> such side effects.
>
> Currently, the only way to do so is to understand the "implementation 
> details" of which variables will be captured, and perhaps add dummy 
> statements like "$foo = null;" or "unset($foo);" to make sure of it.

There's two different issues you're raising here that almost seem to be contradictory.

1. Auto-capture could still over-capture without people realizing it.  Whether this is actually an issue in practice (or would be) is hard to say with certainty; I'm not sure if it's possible to make an educated guess based on a top-1000 analysis, so we're all trying to predict the future.  Note, however, that this risk is already present for short-closures, as the capture logic is the same.

Arguably it's less of an issue only because short-closures are, well, short, so less likely to reuse variables unintentionally.  However, based on my top-1000 survey, even today the vast majority of long-closures are only 2-4 lines long.  I don't believe that makes it 2-4 times more likely, as it's still trivial for a developer to look at a 2 line closure and say "oh, I'm reusing that variable name, maybe that's not as clear as it could be."

2. The syntactic indicator that "auto capture will happen".  The RFC says "fn".  You're recommending "use(*)".  However, changing the indicator syntax would do nothing to improve point 1.  It's just a longer indicator to use the same logic, especially as it would also require the full "function" word.  (Making fn and function synonyms sounds like it would have a lot more knock-on effects that feel very out of scope at present.)  

--Larry Garfield