> On Nov 4, 2025, at 12:18, Larry Garfield <[email protected]> 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
