Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129608
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 15 Dec 2025 15:17:44 -0600
To: "php internals" <internals@lists.php.net>
Message-ID: <d0f8e14b-7e44-45b0-8566-176e30048e1b@app.fastmail.com>
In-Reply-To: <51e16864-0867-4593-a51d-16b8e9fb8fe2@app.fastmail.com>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <51e16864-0867-4593-a51d-16b8e9fb8fe2@app.fastmail.com>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Dec 4, 2025, at 10:46 AM, Larry Garfield wrote:
> On Tue, Nov 4, 2025, at 2:13 PM, Larry Garfield wrote:
>> Arnaud and I would like to present another RFC for consideration: 
>> Context Managers.
>>
>> https://wiki.php.net/rfc/context-managers
>>
>> You'll probably note that is very similar to the recent proposal from 
>> Tim and Seifeddine.  Both proposals grew out of casual discussion 
>> several months ago; I don't believe either team was aware that the 
>> other was also actively working on such a proposal, so we now have two. 
>>  C'est la vie. :-)
>>
>> Naturally, Arnaud and I feel that our approach is the better one.  In 
>> particular, as Arnaud noted in an earlier reply, __destruct() is 
>> unreliable if timing matters.  It also does not allow differentiating 
>> between a success or failure exit condition, which for many use cases 
>> is absolutely mandatory (as shown in the examples in the context 
>> manager RFC).
>>
>> The Context Manager proposal is a near direct port of Python's 
>> approach, which is generally very well thought-out.  However, there are 
>> a few open questions as listed in the RFC that we are seeking feedback 
>> on.
>>
>> Discuss. :-)
>
> More updates to Context Managers:
>
> * We have added "masking" for the context variable, using essentially 
> the same technique as the block scope RFC.
> * We have added support for `try using`, as a shorthand for when you 
> want to wrap a try-catch-finally around a using statement anyway.
>
> More details of both are in the RFC.
>
> As no one seems to have a strong opinion on `continue`, we will most 
> likely proceed with the current approach of matching `switch` behavior.
>
> There doesn't seem to be much interest in making `using` an expression, 
> which I find unfortunate, but that means we'll probably drop that.  
> Fortunately it is probably possible to change in the future if the need 
> arises (the way `throw` was changed).
>
> --Larry Garfield

Since the only feedback on what to use for "as" was that => makes sense, we have changed the RFC to use => instead.  So the new syntax is

using (new CM() => $cVar) {
  // Do stuff here.
}

--Larry Garfield