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