This would lead to inconsistent behavior in the language when short
closures auto capture without the auto keyword while multi statements
closure doesn't.
One of the best features of these RFC are their cognitive definition that
is clear, concise, consistent and simple.

On Sun, Mar 28, 2021, 11:26 Kalle Sommer Nielsen <ka...@php.net> wrote:

> Hi Rowan
>
> Den lør. 27. mar. 2021 kl. 18.05 skrev Rowan Tommins <
> rowan.coll...@gmail.com>:
> > 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:
> >
> > $results = getLargeReportFromDatabase();
> > // ...
> > $fn = fn() {
> >      $results = []; // coincidentally the same name, immediately
> > assigned its own value
> >      // ...
> > }
> > unset($results); // does not free the array, because $fn has captured
> > the value
>
> I too am very concerned about this exact senario because it very
> easily overlooked. While I understand the appeal of having very short
> closures, I do think that such behavior needs to be explicit and would
> much rather prefer something like this:
>
>  - Make the `fn` keyword an alias of the `function` keyword
>  - Add a new `auto` (or similar)  keyword for explicit auto capture
>
> Something like this:
> ```php
> return function () use ($v1, $v2, $v3, $v4) {
>     /* ... */
> };
> ```
>
> Would then be abled to be turned into:
> ```php
> return auto fn () {
>     /* ... */
> };
> ```
>
> That way it is very clear that the closure is intending on auto
> capturing at this point, at the same time it also allows people like
> me who prefers the `function` keyword to write.
>
> I personally don't think adding those 5 extra characters here for
> explicitity is bad, I would like explicitly over implicitit, I can see
> how many would simply just write `fn` without knowing there is a very
> vitual difference (similar to `static` closures is rare if you don't
> intend on binding `$this`).
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Reply via email to