Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118134
MIME-Version: 1.0
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <84eb5551-cfaa-42e6-9a74-ae229d5e269c@www.fastmail.com> <CA+kxMuQypoAwpuQgxougaw62+u0VjMmeoeSJ+N8W6NxRknj9ug@mail.gmail.com>
 <50894bde-74cc-b5a4-4bb7-ba0e682f952c@gmail.com> <CAPzBOBO6U+Vt0YdKUo1JFKtDxfsdP=Pv925m-Dn-K39R_zDmJw@mail.gmail.com>
 <2dcd5fe0-7284-138b-990c-512966141951@gmail.com> <CA+kxMuTD5BN-nmUHK3ebTsw9b5M5puyPn_XM5gVOND_qVwas4Q@mail.gmail.com>
In-Reply-To: <CA+kxMuTD5BN-nmUHK3ebTsw9b5M5puyPn_XM5gVOND_qVwas4Q@mail.gmail.com>
Date: Thu, 30 Jun 2022 16:18:44 +0200
Message-ID: <CAPzBOBPYPzCNUodvoaS+58Oq5tr=CmxkuinJQe_A8Aj38qpsxQ@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: landers.robert@gmail.com (Robert Landers)

On Thu, Jun 30, 2022 at 3:26 PM Dan Ackroyd <Danack@basereality.com> wrote:
>
> Hi Rowan,
>
> Rowan wrote:
> > For that to work, it would require the variable to be captured by
> > reference, not value.
> > ...
> > The only way for it to work would be using capture by reference (not
> > supported by the proposed short syntax):
>
> I wrote about this before. Some of the words in the RFC are, in my
> opinion, quite inaccurate:
>
> Danack wrote in https://news-web.php.net/php.internals/117938 :
> > Those statements are true for scalar values. They are not true for objects:
>
> With automatic capturing of variables, for the code example I gave the
> user would want the variable to be captured, and to them it looks like
> it should be, but because of an optimization it is not.
>
> When the code doesn't work as they expect it to, the programmer is
> likely to add a var_dump to try to see what is happening. Which makes
> it look like their code 'should' work, as their resource object is
> still alive.
>
> > In fact, the "optimisation" is in my opinion a critical part of the
> > semantics, to avoid the opposite problem:
>
> As I said, I think that problem is a lot easier to explain "either use
> long closures or change your variable name if you don't want it
> captured." than trying to explain "yes, the variable is referenced
> inside the closure, but it's not captured because you aren't reading
> from it".
>
> cheers
> Dan
> Ack
>
>
> For this code, comment the var_dump in/out to affect the lifetime of the object.
>
> class ResourceType
> {
>     public function __destruct() {
>         echo "Resource is released.\n";
>     }
> }
>
> function get_callback()
> {
>     $some_resource = new ResourceType();
>     $fn = fn() {
>         // // why is my lock released?
>         var_dump($some_resource);
>         // "Free that resource"
>         $some_resource = null;
>     };
>     return $fn;
> }
>
> $fn = get_callback();
> echo "Before callback\n";
> $fn();
> echo "After callback\n";
>
> // Without var_dump
> Resource is released.
> Before callback
> After callback
>
> // With var_dump
> Before callback
> object(ResourceType)#1 (0) {
> }
> After callback
> Resource is released.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Rowan wrote:
> No, the captured value is tied to the lifetime of the closure itself,
not the variable inside the closure.

With the "optimization," it won't be captured at all by the closure,
possibly causing some resources to go out of scope early. Are
optimizations going to be applied to single-line arrow functions (I
didn't see that in the RFC, but I admittedly didn't look that hard and
I vaguely remember reading something about it in one of these
threads)? If so, it will probably change some behaviors in existing
applications if they were relying on it. Perhaps static analysis tools
can detect this and inform the developer.

Here's Dan's code: https://3v4l.org/99XUN#v8.1.7 that he just sent,
modified to not capture the $some_resource and you can see that it is
indeed released earlier than if it were captured.