> On Mar 27, 2021, at 12:05 PM, Rowan Tommins <rowan.coll...@gmail.com> wrote: > > On 27/03/2021 00:05, Nuno Maduro wrote: >> >> I've just added a few more tests with the exact examples you have presented >> in this mail list: >> https://github.com/php/php-src/pull/6246/commits/c3a50d671c5d8fa4b775ec67fe77d0cbd5cc8030 >> >> <https://github.com/php/php-src/pull/6246/commits/c3a50d671c5d8fa4b775ec67fe77d0cbd5cc8030>. > > > Hi Nuno, > > Thanks, I hadn't thought of writing out test cases, that makes a lot of > sense; although I now realise my question wasn't very clear. > > My biggest concern with automatic capture is the potential for *accidentally* > capturing variables - that is, intending to introduce a local variable inside > the closure, but capturing a variable from the outer scope that happens to > have the same name. This is less of an issue with capture by value, but can > still mean resources not being freed, e.g. a large array of data not being > freed from memory, or an object destructor not executing when expected. > > This is more likely in PHP than many other languages, because there is no > requirement, or even an option, to explicitly declare a local variable in the > closure. It's not a new problem, but since single-expression closures are > unlikely to use many local variables, it's probably not one that's been given > lots of thought. > > > I've written some tests that demonstrate the current behaviour using an > object destructor: > https://github.com/nunomaduro/php-src/commit/ae18662cc92f5d07520b4574dcae71d38a9e0a41 > > Based on those, there seems to be no way to prevent a variable being > captured, even if its value is immediately discarded each time the closure > runs. This may be less than ideal: > > $results = getLargeReportFromDatabase(); > // ... > $fn = fn() { > $results = []; // coincidentally the same name, immediately assigned its > own value > // ... > } > unset($results); // does not free the array, because $fn has captured the > value
In this case doesn't $results get released when $fn goes out of scope? IOW, if fn() is used and discarded by the end of the function in which is it declared then this accidental capture is not an issue (unless it breaks the outer code, of course), right? If it breaks in the outer code then I would say that is not really any different than overwriting the variable in a later loop, for example. So not really an indictment of auto-capture. It is only if the function allows the closure to live on by returned it directly or indirectly, assigning it to a by-reference parameter or assigning to a property of an object that was passed in that it can "leak." Which then begs the question of "How often do closure get returned in a manner they have a long life AND a large number of the same types of closures are created? I can envision how that might happen, but I question how common that scenario would be? And finally, most to the time a PHP page terminates after a page load thus releasing all these captured variables. Yes CLI apps and "Fiber" apps might be different, but they are certainly less common than request/response web pages. IOW, it feels like there would need be a confluence of many factors that collectively are likely rare before this scenario could become a real problem. Where one solution would be, of course, to not write long functions such that it is hard to identify accidentally captured variables. Which seems like a best practice anyway? Did I get anything wrong above? I don't think so but then I could well have missed something. In summary, is this accidental-capture-which-turns-into-a-resource-leak actually a problem worth worrying about? > I wonder if the capture analysis could be made smarter to make this less > likely. > > > PS I'd like to apologise if some of my messages in this thread have come > across as harsh or demanding, I do appreciate you bringing up this feature, > as I know it's one a lot of people want, even if I'm sceptical. > > Regards, > > -- > Rowan Tommins > [IMSoP] > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
