Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130636
Feedback-ID: i8414410d:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Tue, 14 Apr 2026 13:18:11 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <2da81f2d-7c41-46fe-9fb2-1b1cc6be8970@app.fastmail.com>
In-Reply-To: <bbcb85c8-9e59-47d5-8da7-c98e2877901a@bastelstu.be>
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>
 <bbcb85c8-9e59-47d5-8da7-c98e2877901a@bastelstu.be>
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, Apr 14, 2026, at 8:35 AM, Tim D=C3=BCsterhus 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 lea=
d=20
> to a conclusion of "neither approach is obviously better and both have=20
> downsides" and the addition of a secondary vote, particularly one with=20
> voting options using a "suggestive question" wording.
>
> Secondary votes are for multiple equally-valid options that *directly*=20
> relate to the RFC in question, not to have a backdoor to ship changes =
to=20
> PHP with less than a 2/3 majority. The RFC policy is quite clear on=20
> that:
>
>> Combining multiple proposals into one RFC MUST NOT be used to turn a=20
>> primary vote into a secondary vote.
>
> In this case this secondary vote would (potentially; depending on the=20
> result) break the expectation that exchanging `break` with `continue`=20
> and vice versa will continue (pun not intended) to target the same=20
> control structure and add more special cases to the languages. This is=
 a=20
> semantic change that is unrelated to context managers, and thus would =
be=20
> something requiring a 2/3 vote - or better: Something that should just=20
> not happen.
>
> I find it extremely disrepectful to use loaded language like "quirk" t=
o=20
> refer previously established design decision that you don't understand=20
> 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 link=
ed 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 kin=
da 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 ques=
tion.  I have indeed not checked that part of the engine; if you would l=
ike to provide data to show Nikita's description was/is wrong, I will ha=
ppily 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 qu=
estion to ask outside of an RFC introducing `using`. =20

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 agre=
e with your argument is completely uncalled for.  If that part of the RF=
C 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 myse=
lf 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 de=
cided to revert back to the original RFC design, with `continue` mirrori=
ng `switch`'s behavior (do the same as `break` but trigger a Warning), b=
ased on Rowan's feedback.  I dislike the idea of a new feature that incl=
udes 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 updati=
ng the RFC accordingly shortly.  (This will eliminate the secondary vote=
.)

--Larry Garfield