Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118156
MIME-Version: 1.0
References: <e506a378-2060-4cc1-98a6-3c9c7c0bd903@www.fastmail.com>
In-Reply-To: <e506a378-2060-4cc1-98a6-3c9c7c0bd903@www.fastmail.com>
Date: Fri, 1 Jul 2022 20:00:41 +0100
Message-ID: <CA+kxMuTUoj5C52O1BnoOF5S9cL+vRy242NgEBeJ_FwMWB6SCxA@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] [RFC][Vote] Auto-capture closures
From: Danack@basereality.com (Dan Ackroyd)

On Fri, 1 Jul 2022 at 15:05, Larry Garfield <larry@garfieldtech.com> wrote:
>
> The vote for auto-capture closures is now open.  It will run until 15 July.

Voting no as:

i) changes in the implementation need more than 1.5 hours discussion
between that change and the voting opening.

ii) The inconsistency of capturing rules between this RFC and arrow
functions are "not obviously" the correct choice. And definitely need
more than 90 minutes of thinking about.

iii) Some of the phrases in the RFC are still just not true.

"Capture is by-value, no unintended side-effects"
"A by-value capture means that it is not possible to modify any
variables from the outer scope"
"Because variables are bound by-value, the confusing behaviors often
associated with closures do not exist."

They are true for scalar values, but not for objects.

RFCs need to be written clearly so that people don't get the wrong
impression if the don't read every single word.

btw for my concerns about object capturing and RAII, the manual could
probably say something like:

> If you want to ensure an object is captured you can either assign it to itself:
>
> $foo = $foo;
>
> Or create an empty function:
>
> function ensure_variables_stays_alive(mixed $variable)
> {
>    /* function is intentionally blank */
> }
>
> and call that function with the variable you want to stay alive inside the closure.

But again, this is "not obviously" the correct choice.

Dan
Ack