Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117916
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.7.0-alpha0-692-gb287c361f5-fm-20220603.003-gb287c361
Mime-Version: 1.0
Message-ID: <2279cbd2-fcfe-460f-97f9-0029b7b043bb@www.fastmail.com>
In-Reply-To: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
Date: Sun, 12 Jun 2022 12:21:26 -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 Thu, Jun 9, 2022, at 11:34 AM, 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.  That RFC didn't fully go to completion 
> due to concerns over the performance impact, which Nuno and I didn't 
> have bandwidth to resolve.
>
> Arnaud Le Blanc has now picked up the flag with an improved 
> implementation that includes benchmarks showing an effectively net-zero 
> performance impact, aka, good news as it avoids over-capturing.
>
> The RFC has therefore been overhauled accordingly and is now ready for 
> consideration.
>
> https://wiki.php.net/rfc/auto-capture-closure

A little data:

I used Nikita's project analyzer on the top 1000 projects to get a rough sense of how long-closures are used now.  All usual caveats apply about such survey data.  I was specifically looking at how many `use` statements a closure typically had, and how many statements it typically had.  Mainly, I am interested in how common "really long closures where the developer is likely to lose track of what is and isn't closed over" are.

Total closures: 20052
Total used variables: 11534

Avg capture per closure: 0.575
Avg statements per closure: 0.575

Used variable distribution (# of use variables => how many times that happens): 
        0 => 12833
        1 => 4585
        2 => 1667
        3 => 591
        4 => 198
        5 => 98
        6 => 43
        7 => 16
        8 => 9
        9 => 6
        10 => 2
        11 => 4

Statement count distribution (# of statements => how many times that happens): 
        0 => 266
        1 => 13134
        2 => 2885
        3 => 1598
        4 => 818
        5 => 429
        6 => 284
        7 => 176
        8 => 125
        9 => 88
        10 => 48
        11 => 58
        12 => 25
        13 => 27
        14 => 14
        15 => 16
        16 => 13
        17 => 7
        18 => 3
        19 => 7
        20 => 4
        21 => 5
        22 => 3
        23 => 2
        24 => 3
        26 => 2
        27 => 1
        29 => 1
        30 => 1
        35 => 1
        36 => 1
        42 => 1
        44 => 1
        48 => 1
        59 => 1
        69 => 1
        103 => 1
        122 => 1

Analysis:

* The bulk of closures close over nothing, so are irrelevant for us.
* The bulk of closures use only one statement.  That means they could easily be short-lambdas today, and are likely just pre-7.4 code that no one has bothered to update.
* The overwhelming majority of the rest are 2-3 lines long.  The dropoff after that is quite steep.  (Approximately halving each time, with a few odd exceptions.)
* Similarly, most `use` clauses contain 1-2 variables, and the dropoff after that is also quite steep.
* There's some nitwit out there writing 122 line closures, and closing over 11 variables explicitly.  Fortunately it looks like an extremely small number of nitwits. :-)

The primary target of this RFC is people writing 2-4 line closures that import 1-2 variables, both easily small enough that there should be very little risk of developers getting confused by their own code.  Based on the data above, I conclude that group is very much the typical case for closures already, and thus the risk of this syntax resulting in harder to follow code where developers get confused about what is imported and what isn't is very low.

--Larry Garfield