Re: [RFC] Context Managers
| From: | Tim Düsterhus | Date: | Tue, 14 Apr 2026 13:35:02 +0000 |
| Subject: | Re: [RFC] Context Managers | ||
| References: | 1 2 3 4 5 6 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-130629@lists.php.net to get a copy of this message | ||
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 tryis 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