Re: [RFC] Context Managers

On Tue, Apr 14, 2026, at 16:18, Rob Landers wrote: > > > On Tue, Nov 4, 2025, at 21:13, 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. :-) >> >> -- >> Larry Garfield >> larry@garfieldtech.com >> > > Hi Larry/Arnaud, > > This is a pretty exciting thread and fascinating proposal. That being said, I have a couple of > subtle questions that don't seem to be answered in the (very long) thread or the RFC itself -- > If I missed it, please let me know: > 1. What happens if a Fiber is suspended in the using block and never resumed? When is the > using block released to clean up the context? > 2. There's still no mention of how this should affect debugging, will we see the > "desugared" or "sugared" version? Is that even a concern for the RFC? > 3. I will say it is weird to have exitContext return an exception; but what happens if an > exception is thrown during exitContext? Why not just have it return void and throw if you need to > throw instead of having two paths to the same thing? > 4. Looking at the desugared form ... I'm a bit confused: if exitContext is called during > the finally path and returns an exception, it is just swallowed? But if it is thrown, it won't > be? > 5. That being said, I don't think the RFC shares with us when we should return an > exception vs. throw an exception. > > — Rob Maybe the desugared version should look more like this? } catch (\Throwable $e) { try { $__mgr->exitContext($e); } catch (\Throwable $cleanupException) { throw new ContextManagerException( $cleanupException->getMessage(), previous: $e ); } throw $e; } — Rob