On Thu, 9 Jun 2022 at 17:34, Larry Garfield <la...@garfieldtech.com> wrote: > > That RFC didn't fully go to completion due to concerns over the performance > impact
I don't believe that is an accurate summary. There were subtle issues in the previous RFC that should have been addressed. Nikita Popov wrote in https://news-web.php.net/php.internals/114239 > I'm generally in favor of supporting auto-capture for multi-line closures. > > There are some caveats though, which this RFC should address: > > Subtle side-effects, visible in debugging functionality, or through destructor > effects (the fact that a variable is captured may be observable). I think it > nothing else, the RFC should at least make clear that this behavior > is explicitly unspecified, and a future implementation may no longer capture > variables where any path from entry to read passes a write. To be clear, I don't fully understand all those issues myself (and I have just enough knowledge to know to be scared to look at that part of the engine) but my understanding is that the concerns are not about just performance, they are deep concerns about the behaviour. It would produce a better discussion if the RFC document either said how those issues are resolved, or detail how they are still limitations on the implementation. It also probably would have been better (imo) to create a new RFC document. The previous RFC went to vote, even if the vote was cancelled. Diskspace is cheap. Having different (though similar) RFCs under the same URL makes is confusing when trying to understand what happened to particular RFCs. cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
