Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113820
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
In-Reply-To: <3d453ce7-db16-fb75-91b4-9a2a71994164@gmail.com>
Date: Sat, 27 Mar 2021 22:49:11 -0400
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <28DB910B-957D-4E63-A157-F6BEEA68A782@newclarity.net>
References: <88c9eb5f-f80c-4869-b7f8-1b58b9e2eaa3@www.fastmail.com>
 <605bae82.1c69fb81.f49f7.d11eSMTPIN_ADDED_MISSING@mx.google.com>
 <919e30e7-3e5e-d955-7bb4-1e1b5825cdd1@gmail.com>
 <635DD146-FC6F-4991-8D2C-5A6B492722D5@newclarity.net>
 <734f12de-da98-6b76-c2fe-8682f4d177aa@gmail.com>
 <CALZWoqXZF9wegVGwGMjjVEV89zTjb-TYS87MqP36fSk-qJqD4g@mail.gmail.com>
 <daffe9ec-3163-25cc-bb52-587fbd2230bb@gmail.com>
 <36E45DD6-E2BD-4801-BAAE-4355C83D1AC3@newclarity.net>
 <CAJpLVh0ihALcqdGOCeKQ7DDXTHqOvoSW1K2SDO=VEtaJUab7zA@mail.gmail.com>
 <15AE4315-A456-4ED8-990A-49EBD76C5B46@newclarity.net>
 <CAJpLVh0PTjXY3ov2-XppYBR3Z4eskhMQx9xUB7egVwy0nRiFpw@mail.gmail.com>
 <BD2A7A81-C3F7-4738-8237-25B6FB776C3F@newclarity.net>
 <CAJpLVh25PkPEomTjfXJpdGxRx6MhQBLL0JnHajJkaniOTSDtFQ@mail.gmail.com>
 <5501FE70-FBED-47EB-8010-173644BC064F@newclarity.net>
 <CAJpLVh1s6bhLx_S2XBQQDe6CYf+JCM2gOQ2Wgsf3UCcU9-KCnQ@mail.gmail.com>
 <CALZWoqU5jCbC+RBZ7gxMWFDo1Qr8Es2gu=x0Sz06wL1E6NgP-Q@mail.gmail.com>
 <3d453ce7-db16-fb75-91b4-9a2a71994164@gmail.com>
To: Rowan Tommins <rowan.collins@gmail.com>
Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and
 shortfunctions take 2
From: mike@newclarity.net (Mike Schinkel)

> On Mar 27, 2021, at 12:05 PM, Rowan Tommins <rowan.collins@gmail.com> =
wrote:
>=20
> On 27/03/2021 00:05, Nuno Maduro wrote:
>>=20
>> 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/c3a50d671c5d8fa4b775ec67f=
e77d0cbd5cc8030 =
<https://github.com/php/php-src/pull/6246/commits/c3a50d671c5d8fa4b775ec67=
fe77d0cbd5cc8030>.
>=20
>=20
> Hi Nuno,
>=20
> 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.
>=20
> 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.
>=20
> 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.
>=20
>=20
> I've written some tests that demonstrate the current behaviour using =
an object destructor: =
https://github.com/nunomaduro/php-src/commit/ae18662cc92f5d07520b4574dcae7=
1d38a9e0a41
>=20
> 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:
>=20
> $results =3D getLargeReportFromDatabase();
> // ...
> $fn =3D fn() {
>     $results =3D []; // 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? =20=


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.=20

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.
>=20
>=20
> 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.
>=20
> Regards,
>=20
> --=20
> Rowan Tommins
> [IMSoP]
>=20
> --=20
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>=20