Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130641
Precedence: list
MIME-Version: 1.0
Date: Wed, 15 Apr 2026 17:36:26 +0200
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Context Managers
In-Reply-To: <2da81f2d-7c41-46fe-9fb2-1b1cc6be8970@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>
 <02dbe23bb5a4e53be7bf2db7506e07b6@bastelstu.be>
 <841b8e97-9052-4868-badc-1dd1dad0e99a@app.fastmail.com>
 <bbcb85c8-9e59-47d5-8da7-c98e2877901a@bastelstu.be>
 <2da81f2d-7c41-46fe-9fb2-1b1cc6be8970@app.fastmail.com>
Message-ID: <4c1b86fd8214d614b0c4ab56c3ab9f5b@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-04-14 20:18, schrieb Larry Garfield:
> I similarly find it extremely disrespectful to presume malicious intent 
> where there is none.

To provide context as to what happened from my point of view: Both Rowan 
and I explained why "continue == break" is important for language 
consistency, with Rowan even doing the research in the list archives to 
provide the explanation that your email 
(https://news-web.php.net/php.internals/130500) claimed was "lost to 
history". Neither of us received any further reply on-list, until the 
generic "we updated the RFC" roughly a week after. Looking at the 
changes in the RFC then reveals that the "historic" explanation had been 
taken out of context (see below) and a secondary vote with misleading 
voting options had been added.

The only possible explanations I could find for that outcome were "lack 
of diligence", "misunderstanding", and "intent". Given this RFC has two 
authors, I assumed that any changes to the RFC would have been 
cross-checked by both authors, which I would expect to catch accidental 
mistakes arising from a lack of diligence or a misunderstanding (e.g. 
due to language barriers), which then left "intent".

If this assumption of "intent" is incorrect and it's one of the other 
options instead, I apologize for drawing this incorrect conclusion. But 
I find it problematic that this kind of oversight makes it into 2-author 
RFC.

> The "loaded language" you refer to is in reference to a statement by 
> Nikita Popov in the thread that Rowan previously linked to.  Quoting 
> him again:
> 
>> In PHP "switch" is considered a looping structure, for this reason
> "break" and "continue" both apply to "switch", as aliases.

That is correct, but it is taken out of context. The rest of the 
paragraph that immediately follows that quote is explaining why "switch 
is considered a looping structure". Let me include it here:

> [...] For PHP, these are reasonable semantics, as PHP supports 
> multi-level breaks. It would be very questionable if "break N" and 
> "continue N" could refer to different loop structures just because 
> there is a "switch" involved somewhere.

And other emails in that discussion thread, including Rowan's own (which 
he linked in his previous reply), agreed with that. Given that the 
discussion back then resulted in a change to the language (even if not 
via a formal accepted RFC), I believe it is a reasonable assertion that 
"break == continue" is a intentional part of PHP's language design that 
cannot be disregarded in passing.

> That would certainly qualify as a "quirk" in my book, because that's 
> kinda weird and unlike any other language.  Now, if that description is 
> not accurate (or was at the time and no longer is), that's a different 
> question.  I have indeed not checked that part of the engine; if you 
> would like to provide data to show Nikita's description was/is wrong, I 
> will happily accept it.

I refer to Rowan's email here: 
https://news-web.php.net/php.internals/130591. In any case "quirk" or 
similar (negatively) connotated words are inappropriate for use in an 
RFC, which is a document that should accurately and unambiguously 
describe a change that is proposed to be made to PHP (or the PHP 
project's governance in case of policy RFCs). Readers should be able to 
make their own judgement based on the stated facts and well-justified 
decisions. A little more "flowery" language to describe the high-level 
goals of the RFC can be okay - particularly in the "Introduction" and 
"Examples" sections, which are intended to showcase what the RFC will 
enable. But deep in the semantics section of an RFC precise language is 
important for readers to build an informed decision.

> The secondary vote was, specifically, "here's a new feature, `using`, 
> how should this existing feature, `continue`, interact with it?"  That 
> is directly related to the RFC in question; it would be a meaningless 
> question to ask outside of an RFC introducing `using`.

I don't think it is reasonable to consider "continue" and "break" to be 
two separate features given how closely they are related, both in PHP 
and in other programming language. Both in PHP's implementation and in 
PHP's documentation. Tutorials introducing "break" are usually 
introducing "continue" at the same time. And following from that, the 
secondary vote would affect the existing design of an unrelated feature.

> You have made your opinion on this feature quite clear.

I believe that sufficient references have been provided that allow me to 
reasonably say that this is not just an "opinion". For the related 
"should break target using() in the first place" question this is 
something one can have an "opinion" on - one that I personally disagree 
with. The difference is that neither choice there breaks long-standing 
user expectations with regard to the language's behavior, which makes 
them equally valid.

> This will eliminate the secondary vote.

Thank you.

Best regards
Tim Düsterhus