Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:117932
Message-ID: <48f4f560-c051-5b14-9434-d28dcc34184e@gmail.com>
Date: Mon, 13 Jun 2022 14:13:34 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Content-Language: en-GB
To: internals@lists.php.net
References: <2b35605f-8da8-46b1-aec3-00bd1bfe47fd@www.fastmail.com>
 <CA+kxMuTPWbofHLVyuHrrm4dFCykp9R+V39=ygFsvon1u0xXpAw@mail.gmail.com>
 <3564811.oiGErgHkdL@arnaud-t490>
In-Reply-To: <3564811.oiGErgHkdL@arnaud-t490>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] [RFC] Short Closures 2, aka auto-capture take 3
From: rowan.collins@gmail.com (Rowan Tommins)

On 13/06/2022 13:29, Arnaud Le Blanc wrote:
> Following your comment, I have clarified a few things in the "Auto-capture
> semantics" section. This includes a list of way in which these effects can be
> observed. These are really marginal cases that are not relevant for most
> programs.


I'm not sure I agree that all of these are marginal, or with the way 
you've characterised them...


 > Note that destructor timing is undefined in PHP, especially when 
reference cycles exist.

Outside of reference cycles, which are pretty rare and generally easy to 
avoid, PHP's destructors are entirely deterministic. Unlike in fully 
garbage-collected languages, you can use a plain object to implement an 
"RAII" pattern - e.g. the constructor locks a file and the destructor 
unlocks it; or the constructor starts a transaction, and the destructor 
rolls it back if not yet committed.

A related case is resource lifetime: file and network handles are 
guaranteed to be closed when they go out of scope, and accidentally 
taking an extra copy of their "value" can prevent that.


 > It ends up capturing the same variables that would have been captured 
by a manually curated |use| list.

This slightly muddles two different questions:

1) Given a well-written closure, where all variables are either clearly 
local or clearly intended to be captured, does the implementation do a 
good job of distinguishing them?
2) Given a badly-written closure, where variables are accidentally 
ambiguous, what side-effects might the user experience?

The answer to question 1 seems to be yes, the implementation does a good 
job, and that's good news, and thank you for working on it.

That is not the same, however, as saying that question 2 is never 
relevant. Consider the following, adapted from an example in the RFC:

$filter = fn ($user) {
     if ( $user->id !== -1 ) {
         $guest = $repository->findByUserId($user->id);
     }
     return isset($guest) && in_array($guest->id, $guestsIds);
};

This is not particularly great code, but it works ... unless the parent 
scope happens to have a variable named $guest, which will then be bound 
to the closure, since there is a path where it is read before being 
written. In this case, side effects include:

* The behaviour will change based on the captured value of $guest
* Any resources held by that value will be held until $filter is 
destructed, rather than when $guest is destructed


Whether the risk of these side effects is a big problem is up for 
debate, but it's wrong to suggest they don't exist.


Regards,

-- 
Rowan Tommins
[IMSoP]