Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130629
Precedence: list
MIME-Version: 1.0
Date: Tue, 14 Apr 2026 15:35:02 +0200
To: Larry Garfield <larry@garfieldtech.com>, php internals
 <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Context Managers
In-Reply-To: <841b8e97-9052-4868-badc-1dd1dad0e99a@app.fastmail.com>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <cf17cf19-f41e-4378-9a82-cb7f1a9d7b70@app.fastmail.com>
 <5d96fca3ca5418e6e9e5d8871b26477f@bastelstu.be>
 <8bf1b0a7-7771-4f81-b92c-49bb019f7f9d@app.fastmail.com>
 <02dbe23bb5a4e53be7bf2db7506e07b6@bastelstu.be>
 <841b8e97-9052-4868-badc-1dd1dad0e99a@app.fastmail.com>
Message-ID: <bbcb85c8-9e59-47d5-8da7-c98e2877901a@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

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