Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130530
Precedence: list
MIME-Version: 1.0
Date: Thu, 02 Apr 2026 12:13:32 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Context Managers
In-Reply-To: <8bf1b0a7-7771-4f81-b92c-49bb019f7f9d@app.fastmail.com>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <cf17cf19-f41e-4378-9a82-cb7f1a9d7b70@app.fastmail.com>
 <5d96fca3ca5418e6e9e5d8871b26477f@bastelstu.be>
 <8bf1b0a7-7771-4f81-b92c-49bb019f7f9d@app.fastmail.com>
Message-ID: <02dbe23bb5a4e53be7bf2db7506e07b6@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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