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

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Reply via email to