On Tue, Apr 14, 2026, at 8:35 AM, Tim Düsterhus wrote: > 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.
I similarly find it extremely disrespectful to presume malicious intent where there is none. 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 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. As far as it being a "backdoor" change to another feature... once again, you seem to be assuming subterfuge or malicious intent without evidence. 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`. You have made your opinion on this feature quite clear. Others disagree. Accusing us of trying to sneak around the rules because we don't agree with your argument is completely uncalled for. If that part of the RFC is enough for you to vote against the RFC over, that is certainly your right, and I've certainly voted against RFCs I otherwise supported myself due to smaller design decisions. But that is not grounds to make the baseless accusations you're making here. Prior to your post, Arnaud and I had already discussed it further and decided to revert back to the original RFC design, with `continue` mirroring `switch`'s behavior (do the same as `break` but trigger a Warning), based on Rowan's feedback. I dislike the idea of a new feature that includes a Warning out of the gate (which is why it's been an open question of discussion), but it seems to be the least-bad option. I'll be updating the RFC accordingly shortly. (This will eliminate the secondary vote.) --Larry Garfield
