On Sun, Mar 29, 2026, at 6:14 AM, Tim Düsterhus 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 make
>> it sleaker and more consistent. The notable ones (that impact
>> behavior) are as follows:
>
> “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."
>> 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.
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...
break is the natural keyword for that, as it already means "stop this control
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 don't see a reason to
propagate that mistake.
>> 2. Several people (including us) were uncomfortable with using a
>> boolean return from the exitContext() method. While that is what
>> Python does, it is indeed not self-evident how it works. (Should true
>> mean "true, I'm done" or "true, rethrow"?) We debated using an enum
>> value, but that appeared to be too verbose.
>>
>> Instead, we decided that exitContext() should return ?Throwable, which
>> is the same thing it is passed. In a success case, it is passed null.
>> In a failure case, it is passed a throwable. So it can then return
>> null (meaning "we're done, nothing else to do here") or a throwable,
>> which will then get thrown. Since in most cases an error should be
>> allowed to propagate, it means simply calling `return $exception` at
>> the end of the method will "do the right thing" 95% of the time.
>> Simple and easy and self-documenting. (If there's a reason to wrap and
>> rethrow the exception, do that and return the new exception. Or to
>> swallow the exception and not propagate it, return null.)
>
> That sounds like a “throw” statement with extra steps [1]. While nothing
> stopped you from writing `throw new SomeException();` within
> `exitContext()` with the `bool` return value, it at least *encouraged*
> you to not replace the original Exception with another Exception
> entirely and to just make a decision between “suppress” or “not
> suppress”. Now `return` is completely equivalent to `throw` (at least as
> long as `exitContext()` doesn't contain a `catch()` itself) adding even
> more layers of “using() is magically including behavior of other
> language constructs” that will be hard to reason about for humans and
> machines alike.
If you have an alternate suggestion for how to achieve this functionality, 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 code, 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
