Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130500
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 30 Mar 2026 13:48:05 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <8bf1b0a7-7771-4f81-b92c-49bb019f7f9d@app.fastmail.com>
In-Reply-To: <5d96fca3ca5418e6e9e5d8871b26477f@bastelstu.be>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <cf17cf19-f41e-4378-9a82-cb7f1a9d7b70@app.fastmail.com>
 <5d96fca3ca5418e6e9e5d8871b26477f@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Mar 29, 2026, at 6:14 AM, Tim D=C3=BCsterhus wrote:
> Larry,
>
> Am 2026-03-22 19:19, schrieb Larry Garfield:
>> Arnaud and I have made a number of changes to the RFC that should mak=
e=20
>> it sleaker and more consistent.  The notable ones (that impact=20
>> behavior) are as follows:
>
> =E2=80=9CSleaker=E2=80=9D is not a word my dictionary understands. Was=
 this a typo for=20
> =E2=80=9Csleeker=E2=80=9D in the sense of =E2=80=9Crefined=E2=80=9D?

Yes, typo.  Sleeker in the sense of "fewer bumpy parts on it."=20

>> 1. We went back and forth on the `continue` question several times,=20
>> before coming to the conclusion that `continue` is a tool for looping=20
>> structures only.  That `switch` also uses it is just `switch` being=20
>> silly because reasons, and there is no reason `using` must inherit it=
s=20
>> weirdness.  Therefore, `continue` inside a `using` block now means=20
>> nothing at all.  `continue` will ignore it, the same way it ignores a=
n=20
>> `if` statement.
>
> I fail to see how =E2=80=9Cmaking break; and continue; behave inconsis=
tently=E2=80=9D is=20
> making the RFC (and by extension) the language any more consistent. In=20
> this following example snippet it's not at all obvious that the `break=
`=20
> is behaving incorrectly by targeting the `using()` with `continue`=20
> targeting the `foreach()`, despite both using the same =E2=80=9Cnumber=
=E2=80=9D:
>
>      $processed =3D 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 decisi=
on=20
> for `break` to target `using()` has been made. For your reference, my=20
> last email asking that question is this one:=20
> https://news-web.php.net/php.internals/129771. I didn't receive a repl=
y=20
> 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 ca=
se.  An error case is easy (throw), but for a success case we cannot use=
 return, as that will return from the function.

Technically "goto and your own label" would work, but I really hope we d=
on't need to get into a discussion about why making goto the only way to=
 solve something is a bad idea...

break is the natural keyword for that, as it already means "stop this co=
ntrol structure and go to the end of it."

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 d=
on't see a reason to propagate that mistake.

>> 2. Several people (including us) were uncomfortable with using a=20
>> boolean return from the exitContext() method.  While that is what=20
>> Python does, it is indeed not self-evident how it works.  (Should tru=
e=20
>> mean "true, I'm done" or "true, rethrow"?)  We debated using an enum=20
>> value, but that appeared to be too verbose.
>>=20
>> Instead, we decided that exitContext() should return ?Throwable, whic=
h=20
>> is the same thing it is passed.  In a success case, it is passed null=
. =20
>> In a failure case, it is passed a throwable.  So it can then return=20
>> null (meaning "we're done, nothing else to do here") or a throwable,=20
>> which will then get thrown.  Since in most cases an error should be=20
>> allowed to propagate, it means simply calling `return $exception` at=20
>> the end of the method will "do the right thing" 95% of the time. =20
>> Simple and easy and self-documenting.  (If there's a reason to wrap a=
nd=20
>> rethrow the exception, do that and return the new exception.  Or to=20
>> swallow the exception and not propagate it, return null.)
>
> That sounds like a =E2=80=9Cthrow=E2=80=9D statement with extra steps =
[1]. While nothing=20
> stopped you from writing `throw new SomeException();` within=20
> `exitContext()` with the `bool` return value, it at least *encouraged*=20
> you to not replace the original Exception with another Exception=20
> entirely and to just make a decision between =E2=80=9Csuppress=E2=80=9D=
 or =E2=80=9Cnot=20
> suppress=E2=80=9D. Now `return` is completely equivalent to `throw` (a=
t least as=20
> long as `exitContext()` doesn't contain a `catch()` itself) adding eve=
n=20
> more layers of =E2=80=9Cusing() is magically including behavior of oth=
er=20
> language constructs=E2=80=9D that will be hard to reason about for hum=
ans and=20
> machines alike.

If you have an alternate suggestion for how to achieve this functionalit=
y, now is the time to propose it.

Behaviors in the order they're likely to happen (I'd expect):

- Success case, there is no exception
- Keep propagating the exception.
- The exception stops here.
- We're catching the exception and wrapping it in another exception with=
 more useful data on it (exceptions can do that), and then throwing that.

The setup we have now solves all four cases with fairly self-evident cod=
e, and handles the first two cases in the exact same code so most people=
 won't need to really think about it.  If you have a better suggestion, =
please do share.

--Larry Garfield