Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117937
Message-ID: <42cdb2d9-485d-cf5c-4cce-b9c1f8c2084e@gmail.com>
Date: Mon, 13 Jun 2022 18:39:34 +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>
 <2347345.PIDvDuAF1L@arnaud-t490>
 <8422e11c-4a3f-9f99-56ce-884491dfe08e@gmail.com>
 <39470114-2c35-4c71-b8ef-c8d3ce3c3555@www.fastmail.com>
In-Reply-To: <39470114-2c35-4c71-b8ef-c8d3ce3c3555@www.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: rowan.collins@gmail.com (Rowan Tommins)

On 13/06/2022 14:52, Larry Garfield wrote:
>> 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.


It's a difference in focus which is very evident in some of the comments 
on this thread. For instance, Arnaud assumed that adding "use(*)" would 
require a change to arrow functions, whereas that never even occurred to 
me, because we're looking at the feature through a different lens.


>> By the way, the current RFC implies you could write this:
>>
>> fn() use (&$myRef, $a) { $myRef = $a * $b; }
> 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.


So it does. I find that extremely confusing; I think it would be clearer 
to error for that case, changing the proposal to:

 > Short Closures support explicit by-reference capture with the |use| 
keyword. Combining a short closure with explicit by-value capture 
produces an error.

And the example to:

$a = 1;
fn () use (&$b) {
     return $a + $b; // $a is auto-captured by value
                          // $b is explicitly captured by reference
}


Clearer syntax for this has been cited previously as an advantage of 
use(*) or use(...):

$a = 1;
function () use (&$b, ...) { // read as "use $b by reference, everything 
else by value"
     return $a + $b;
}


> 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.


I tried to make very explicit what I was and was not disputing:

 > Whether the risk of these side effects is a big problem is up for 
debate, but it's wrong to suggest they don't exist.

The RFC seems to be implying that the implementation removes the side 
effects, but it does not, it is users paying attention to their code 
which will remove the side effects.


> Arguably it's less of an issue only because short-closures are, well, short, so less likely to reuse variables unintentionally.


Our current short closures aren't just a single *statement*, they're a 
single *expression*, and that's a really significant difference, because 
it means to all intents and purposes *they have no local scope*. (You 
can create and use a local variable within one expression, but it 
requires the kind of twisted code that only happens in code golf.)

If there are no local variables, there is nothing to be accidentally 
captured. That's why the current implementation doesn't bother 
optimising which variables it captures - it's pretty safe to assume that 
*all* variables in the expression are either parameters or captured.


> 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.


The reason I think it would be better is because it is a more 
*intentional* syntax: the author of the code is more likely to think 
"I'm using an auto-capture closure, rather than an explicit-capture 
closure, what effect will that have?" and readers of the code are more 
likely to think "hm, this is using auto-capture, I wonder which 
variables are local, and which are captured?"

Of course they can still guess wrong, but I don't think "fn" vs 
"function" is a strong enough clue.


> (Making fn and function synonyms sounds like it would have a lot more knock-on effects that feel very out of scope at present.)


Off the top of my head, I can't think of any, but I admit I haven't 
tried hacking it into the parser to see if anything explodes.


Regards,

-- 
Rowan Tommins
[IMSoP]