Re: [RFC] Context Managers

Hi Am 2026-03-30 20:48, schrieb Larry Garfield:

“Sleaker” is not a word my dictionary understands. Was this a typo for “sleeker” in the sense of “refined”?

Yes, typo. Sleeker in the sense of "fewer bumpy parts on it."

Okay. I think that updated semantics failed in that goal and instead added additional bumpy parts.

1. We went back and forth on the continue question several times, before coming to the conclusion that continue is a tool for looping structures only. That switch also uses it is just switch being silly because reasons, and there is no reason using must inherit its weirdness. Therefore, continue inside a using block now means nothing at all. continue will ignore it, the same way it ignores an if statement.

I fail to see how “making break; and continue; behave inconsistently” is making the RFC (and by extension) the language any more consistent. In this following example snippet it's not at all obvious that the break is behaving incorrectly by targeting the using() with continue targeting the foreach(), despite both using the same “number”:

     $processed = 0;
     foreach ($entries as $entry) {
         using ($db->transaction()) {
             switch ($entry['type']) {
             case 'EOF':
                 break 2;
             default:
                 if (should_skip($entry)) {
                     continue 2;
                 }

                 $db->insert($entry);
             }
         }

         $processed++;
     }

I'm also noticing that the RFC still does not explain *why* the decision for break to target using() has been made. For your reference, my last email asking that question is this one: https://news-web.php.net/php.internals/129771. I didn't receive a reply to that email either (and neither do the list archives have a reply).

I'm pretty sure I did explain in this thread somewhere... In short, we want a way to be able to terminate the using block early in a success case. An error case is easy (throw), but for a success case we cannot use return, as that will return from the function.

That is a self-referential argument - you made the decision, because you wanted to make the decision. I was looking for an explanation why context managers are sufficiently special that they *need* support for exiting their associated block early *and* why existing control structures are insufficient to handle that. try for example does not support exiting the block early and given that the primary semantics of context managers are that of a try-catch-finally, it is reasonable to ask what makes context managers different. I also note that none of the existing examples in the RFC make use of break, this capability only gets a passing mention. Please provide a use case.

Technically "goto and your own label" would work, but I really hope we don't need to get into a discussion about why making goto the only way to solve something is a bad idea...

No, please elaborate.

break is the natural keyword for that, as it already means "stop this control structure and go to the end of it."

Quoting my the previous email that I linked in the email you were replying to:

“break does a different thing here than it does in if, else, try, catch, finally, namespace, and declare” doesn't seem like a straightforward approach to me.

-

continue means "stop this iteration of a control structure and go to the next one." But in this case, there is no next one. switch makes it an alias for break, for whatever reason lost to history, but given that it now throws a warning that seems to now be considered a mistake, so we don't see a reason to propagate that mistake.

I think Rowan explained that well in his reply.

If you have an alternate suggestion for how to achieve this functionality, now is the time to propose it.

As implied by my email, I believe that throwing exceptions should be the job of the throw keyword, not the job of the return keyword. Otherwise users are going to wonder what makes `return new SomeException(); different from throw new SomeException()` in that case. Best regards Tim Düsterhus