Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117909
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
In-Reply-To: <d568ea21-0378-4ad5-81c4-862a1148a327@www.fastmail.com>
Date: Sun, 12 Jun 2022 04:33:03 -0400
Cc: Larry Garfield <larry@garfieldtech.com>,
 Rowan Tommins <rowan.collins@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <56E24B6F-E29D-41D3-8CF0-B1EBC0DECDB2@gmail.com>
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <8310f3fd-0011-970e-5379-b2b6e03942b2@gmail.com>
 <d568ea21-0378-4ad5-81c4-862a1148a327@www.fastmail.com>
To: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: mike@newclarity.net (MKS Archive)

> On Jun 11, 2022, at 10:01 PM, Larry Garfield <larry@garfieldtech.com> =
wrote:
>=20
> On Sat, Jun 11, 2022, at 4:14 PM, Rowan Tommins wrote:
>> On 09/06/2022 17:34, 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 ... Arnaud Le Blanc has now picked up the =
flag with an improved implementation ... The RFC has therefore been =
overhauled accordingly and is now ready for consideration.
>>>=20
>>> https://wiki.php.net/rfc/auto-capture-closure
>>=20
>>=20
>> First of all, thanks to all three of you for the work on this. =
Although=20
>> I'm not quite convinced yet, I know a lot of people have expressed=20
>> desire for this feature over the years.
>=20
>> To go back to the point about variable scope: right now, if you're in =
a=20
>> function, all variables are scoped to that function. With a tiny =
handful=20
>> of exceptions (e.g. superglobals), access to variables from any other=20=

>> scope is always explicit - via parameters, "global", "use", "$this", =
and=20
>> so on. If we think that should change, we should make that decision=20=

>> explicitly, not treat it as a side-effect of syntax.
>>=20
>> I don't find the comparison to a foreach loop very convincing. Loops =
are=20
>> still only accessing variables while the function is running, not =
saving=20
>> them to be used at some indeterminate later time. And users don't =
"learn=20
>> to recognize" that a loop doesn't hide all variables from the parent=20=

>> scope; it would be very peculiar if it did.
>=20
> There are languages that do, however.  Some languages have =
block-scoped variables by default (such as Rust), or partially blocked =
scoped depending on details.  PHP is not one of them, but to someone =
coming from a language that does, PHP's way of doing things is just as =
weird and requires learning. =20


Working in Go now for several years I'd say one of its biggest foot guns =
that I consistently run into when doing code reviews and even in my own =
code is block-level scoping where one variable shadows the same named =
variable outside the block and the inner variable is updated when the =
intention was to update the outer variable.

In short, block level scoping is a convenience that does more harm than =
good. At least in my experience.

Thus I would highly recommend *not* adding block level variable scope to =
PHP where a block in the middle of a function shadows a variable outside =
the block, and that variable is used below the block, such as for a =
return value. =20

#jmtcw #fwiw

-Mike=