Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:113818
To: internals@lists.php.net
References: <88c9eb5f-f80c-4869-b7f8-1b58b9e2eaa3@www.fastmail.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>
 <4932d1da-1f5e-4210-a2ea-a158595519c6@www.fastmail.com>
Message-ID: <4d1e84cd-4681-11f3-cda0-9361b57bb0a0@gmail.com>
Date: Sat, 27 Mar 2021 19:33:54 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <4932d1da-1f5e-4210-a2ea-a158595519c6@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-GB
Subject: Re: [PHP-DEV] [RFC] Auto-capture multi-line closures and
 shortfunctions take 2
From: rowan.collins@gmail.com (Rowan Tommins)

On 27/03/2021 16:52, Larry Garfield wrote:
> It's a valid point that auto-capture on multi-line function makes the potential for unexpected behavior higher than with a single-line function, simply by virtue of there being more lines of code that could do so.


It's not just about number of lines, but style of code: the vast 
majority of single-expression closures will have zero local variables, 
so the potential for accidentally capturing a variable of the same name 
is also zero.

You're right that it's subjective whether this risk is too high, though. 
I was partly trying to understand what the risk is with the proposed 
behaviour, and also considering whether we can reduce that risk by 
changing the implementation to capture fewer variables.


This did come up in some of the previous discussions. For instance, 
during the discussion of the successful RFC two years ago, Nikita wrote 
[ https://externals.io/message/104693#104738 ]:

 > On the other hand, allowing a block body for the closure does add a 
number
 > of complications to this proposal:
 > [...]
 > 3. Determining bound variables. For single-expression closures we can 
get
 > away with binding all variables that are used inside the closure. 
Writing
 > something like fn() $a = $b might cause an unnecessary binding of $a, 
but
 > it's also a very contrived situation. For block closures performing
 > assignments inside the closure will be much more common and will need 
some
 > more consideration to avoid unnecessary bindings.


Regards,

-- 
Rowan Tommins
[IMSoP]