Re: [RFC] Context Managers

From: Date: Mon, 15 Dec 2025 22:58:30 +0000
Subject: Re: [RFC] Context Managers
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-129610@lists.php.net to get a copy of this message
On Dec 15, 2025, at 16:29, Matthew Weier O'Phinney <mweierophinney@gmail.com> wrote:On Mon, Dec 15, 2025, 3:19 PM Larry Garfield <larry@garfieldtech.com> wrote: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. }Going to be controversial here, but this is confusing, because it operates in the exact opposite of every other usage of => we have. With associative arrays, the left is assigned to the expression on the right; with arrow functions, the return value is the expression on the right; with match, the expression on the right is returned. This is going to be easy to get wrong.  I agree with Matthew. I think it makes more sense to reverse them, like this:    using ($cVar => new CM()) {        // Do stuff here.    }I think it’s still clear what this is doing, when reading it.Cheers,Ben

« previous php.internals (#129610) next »