Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113814
User-Agent: Cyrus-JMAP/3.5.0-alpha0-273-g8500d2492d-fm-20210323.002-g8500d249
Mime-Version: 1.0
Message-ID: <4932d1da-1f5e-4210-a2ea-a158595519c6@www.fastmail.com>
In-Reply-To: <3d453ce7-db16-fb75-91b4-9a2a71994164@gmail.com>
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>
Date: Sat, 27 Mar 2021 11:52:43 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: =?UTF-8?Q?Re:_[PHP-DEV]_[RFC]_Auto-capture_multi-line_closures_and_short?=
 =?UTF-8?Q?functions_take_2?=
From: larry@garfieldtech.com ("Larry Garfield")

On Sat, Mar 27, 2021, at 11:05 AM, Rowan Tommins wrote:
> On 27/03/2021 00:05, Nuno Maduro wrote:
> >
> > I've just added a few more tests with the exact examples you have=20=

> > presented in this mail list:=20
> > https://github.com/php/php-src/pull/6246/commits/c3a50d671c5d8fa4b77=
5ec67fe77d0cbd5cc8030=20
> > <https://github.com/php/php-src/pull/6246/commits/c3a50d671c5d8fa4b7=
75ec67fe77d0cbd5cc8030>.
>=20
>=20
> Hi Nuno,
>=20
> Thanks, I hadn't thought of writing out test cases, that makes a lot o=
f=20
> sense; although I now realise my question wasn't very clear.
>=20
> My biggest concern with automatic capture is the potential for=20
> *accidentally* capturing variables - that is, intending to introduce a=
=20
> local variable inside the closure, but capturing a variable from the=20=

> outer scope that happens to have the same name. This is less of an iss=
ue=20
> with capture by value, but can still mean resources not being freed,=20=

> e.g. a large array of data not being freed from memory, or an object=20=

> destructor not executing when expected.
>=20
> This is more likely in PHP than many other languages, because there is=
=20
> no requirement, or even an option, to explicitly declare a local=20
> variable in the closure. It's not a new problem, but since=20
> single-expression closures are unlikely to use many local variables,=20=

> 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 a=
n=20
> object destructor:=20
> https://github.com/nunomaduro/php-src/commit/ae18662cc92f5d07520b4574d=
cae71d38a9e0a41
>=20
> Based on those, there seems to be no way to prevent a variable being=20=

> captured, even if its value is immediately discarded each time the=20
> closure runs. This may be less than ideal:
>=20
> $results =3D getLargeReportFromDatabase();
> // ...
> $fn =3D fn() {
>  =C2=A0=C2=A0=C2=A0 $results =3D []; // coincidentally the same name, =
immediately=20
> assigned its own value
>  =C2=A0=C2=A0=C2=A0 // ...
> }
> unset($results); // does not free the array, because $fn has captured=20=

> the value
>=20
>=20
> I wonder if the capture analysis could be made smarter to make this le=
ss=20
> likely.
>=20
>=20
> PS I'd like to apologise if some of my messages in this thread have co=
me=20
> across as harsh or demanding, I do appreciate you bringing up this=20
> feature, as I know it's one a lot of people want, even if I'm sceptica=
l.
>=20
> Regards,

It's a valid point that auto-capture on multi-line function makes the po=
tential for unexpected behavior higher than with a single-line function,=
 simply by virtue of there being more lines of code that could do so.  T=
he question is whether that higher risk is worth the improved ergonomics=
.  That is, ultimately, a subjective question, and depends on how much y=
ou think the risk increases (it's non-zero, but that doesn't mean high) =
and how much you think the ergonomics are improved (also non-zero, but h=
ard to quantify).

IMO, it is.  In practice, I can't recall seeing 100 line closures inside=
 100 functions, well, ever.  I mostly see 2-3 line closures in 10 line f=
unctions.  That makes the risk vastly smaller, and in practice I don't t=
hink it will come up much.

Also, bear in mind that in many cases such bugs would become self-eviden=
t very quickly, and you'll know to just rename a variable.

I realize it's completely and totally unscientific, but the social media=
 response to both of these RFCs has been overwhelmingly (although not un=
iversally) positive.  There definitely seems to be demand for "do the sa=
me stuff but with less typing".

--Larry Garfield