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

Reply via email to