Larry,
On 4/7/26 18:20, Larry Garfield wrote:
the continue question (which is now a secondary vote)
I'm really struggling with finding appropriate words in my reply here.
It is not at all clear to me how both Rowan's and my replies could lead
to a conclusion of "neither approach is obviously better and both have
downsides" and the addition of a secondary vote, particularly one with
voting options using a "suggestive question" wording.
Secondary votes are for multiple equally-valid options that *directly*
relate to the RFC in question, not to have a backdoor to ship changes to
PHP with less than a 2/3 majority. The RFC policy is quite clear on
that:
Combining multiple proposals into one RFC MUST NOT be used to turn a
primary vote into a secondary vote.
In this case this secondary vote would (potentially; depending on the
result) break the expectation that exchanging `break` with `continue`
and vice versa will continue (pun not intended) to target the same
control structure and add more special cases to the languages. This is a
semantic change that is unrelated to context managers, and thus would be
something requiring a 2/3 vote - or better: Something that should just
not happen.
I find it extremely disrepectful to use loaded language like "quirk" to
refer previously established design decision that you don't understand
the reasons for or that you disagree with.
With regard to the voting options:
Ignore using blocks entirely, like try
is drawing a faulty comparison, because `break` also ignores `try`. This
is not special behavior of `continue`.
There is a reason as to why things are the way they are. Please do your
research instead of making assumptions and leaving it to others to point
out how the RFC would break PHP's existing well-established language
design.
Best regards
Tim Düsterhus
