Re: [RFC] Context Managers

> On Nov 4, 2025, at 12:18, Larry Garfield <larry@garfieldtech.com> 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, Arnaud, I really like this RFC but have a couple of things to discuss: - automatically re-throwing exceptions: I think that this behavior, especially with a boolean return value deciding if it happens or not is not intuitive. I think a better approach is to do nothing with the exception and let the user re-throw it if desired. I can't think of anywhere else we re-throw exceptions unless the user indicates otherwise. I'd rather leave the return value for return values; we could expand this allow access to the return value like: with (foo() as $foo return $bar) { }, and $bar would be set to null on void returns. - context variable and scope: I know that you explicitly are not creating a new scope, this means that the context variable will clash with the enclosing scope namespace, and then the variable will be unset after the context ends, this doesn't sit so well with me. I think I'd rather see the same behavior as arrow function arguments, where it does not override variables of the same name in the enclosing scope and whatever value it has is lost at the end of the context, leaving the outer scope version intact. At worst though, I'm sure IDE and static analyzers will be able to detect the "use after unset" behavior with clashing variable names, causing the developer to resolve it, and it'll be fine either way. Thanks for the great RFC! - Davey