Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128312
Message-ID: <3ffb9cef-60ad-4fc9-b6dd-502bee6c1c6c@bastelstu.be>
Date: Tue, 29 Jul 2025 23:49:25 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Warnings for PHP 8.5
To: "Gina P. Banyard" <internals@gpb.moe>,
 Ilija Tovilo <tovilo.ilija@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <ClHWqZ8xQp5NMLvOxMZ80CqdIr0QVhrCzJmDZyw0h7Z4CtK3DG8fW3dKbf4fu-WJRxvqBY9S_W29um3mHEaGJ9ee1epItOizujB3CpbNKfA=@gpb.moe>
 <EYKUX_e3wzCF2eOwU5beLQfcpz-0w4K1M5fjdITFJ0yND11XWgFm-bI_zh7hz8sNygSLrRLe8sTWz_vpcXPlq5o83R5QKfI_zxNzMu1w9eU=@gpb.moe>
 <3b303d303708b13a2de81dc07753da3a@bastelstu.be>
 <qHqe_cprXfMx8PAHwaMVUGmJWu94iC0thiRRjwn_hesackCjF6vbZXLie269X7_4AdHcs9By6j_gZX0L6E5aGjHctUCUESFPbC1sDLHd4EE=@gpb.moe>
 <CAPyj-LC03m4RmxBpZJSOdX3EStPRJu2BrRzE971kn-cyZLmHDw@mail.gmail.com>
 <-EPNf2A21qLIrIyEvNmQxV_tNTa1IO5hU-LHGBhjfnVRB33qiwK3yhVV7AxDKSTDUl9ihRpapZLckSgnCn7t9RvUj9Jbtjnx1VLYqCQO6BI=@gpb.moe>
Content-Language: en-US
In-Reply-To: <-EPNf2A21qLIrIyEvNmQxV_tNTa1IO5hU-LHGBhjfnVRB33qiwK3yhVV7AxDKSTDUl9ihRpapZLckSgnCn7t9RvUj9Jbtjnx1VLYqCQO6BI=@gpb.moe>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Preliminary note: I'll be on vacation starting tomorrow and thus might 
not be able to look into further replies. I wanted to get this email out 
of the door nevertheless to check off an open ToDo list item before the 
vacation and because I found it important to not leave the topic sitting 
around for two weeks, while the vote is in progress.

On 7/29/25 11:01, Gina P. Banyard wrote:
> produces zero, which is even more clearly a problem).  After confirming this
> and thinking about it, I wanted to modify my existing wording to account for
> this edge case; doing so would have resulted in very convoluted language,

Requiring “convoluted language” to integrate this into the existing 
proposal to me is an indicator that it is a different proposal and that 
splitting it out into a separate primary vote is the correct choice.

> This is the highest possible bar that I have set: adding the new edge case as a
> secondary vote would have been completely justified, and this would require a
> smaller majority of a vote.  If I was worried about a procedural spanner in the
> works, I could have just shoehorned this minor change into the existing text
> and this would also have been completely justified.  I made the changes in the
> clearest possible way for the benefit of people reading the wiki.

I disagree. The existing policy that you quoted is clear in that 
“Combining multiple RFCs into one does not allow turning a primary vote 
into a secondary vote”. While the current policy indeed does not specify 
that an RFC needs to be “identical” (as you mentioned in your other 
email) and RFCs often evolve, using the RFC title as the identifier and 
scope of an RFC seems to be the intention. Otherwise I could just 
prepare a RFC reserve of “Reserved RFC 1” to “Reserved RFC 9”, formally 
start the discussion on those and then when I have an idea I could 
change the contents as appropriate and immediately call a vote. This 
clearly would be in violation of the spirit of the policy.

I'd argue that “out of range floats” are something different than “NAN 
values”, with the former being larger in scope, since it also affects 
floats that exceed the integer range, instead of just the specific NAN 
value and thus it is not a “subset” that would fit under the same headline.

> I will now open the vote as-is, anyone is free to convince people to simply
> vote against it, or do the most procedurally correct thing of starting an RFC
> to render it void after the fact (regardless of the outcome of this vote).

It does not seem productive to me to hold a vote just to nullify it 
after the fact. I've intentionally made sure to raise my objection 
before the RFC went to vote. In fact you specifically called out in your 
email that you wanted to give folks a few hours to raise objections. It 
is not clear to me why the objection raised would then simply be ignored.

> Regarding the suggestion to simply kick the can down the road to the next
> version: we do not know if the next version will be 9.0, which if the same
> request is made about deprecation as 8.0 had, this would mean the warning for
> this could not be introduced until 9.1, and then it could only be upgraded to
> an error by PHP 10.0. This seems like a disproportionate amount of extra work
> for such a minor change.

I do not understand why new warnings cannot be introduced in PHP 9.0. 
Given that “Warnings” are treated very strongly by the community 
(commonly converting them to Exceptions), I also don't see a pressing 
need to make it an error in the engine. It wasn't an issue for the last 
30 years of PHP's existence, so moving it back another year when it 
missed the deadline seems totally reasonable to me.

> I agree it is important for internals to voice their concerns.  I am simply
> upset that a very minor *procedural* disagreement is once again incentivising
> me to smuggle in common-sense changes through procedural back doors rather than
> write my proposals clearly.  This seems like a clearly positive and minor
> change; anyone who disagrees on *technical* grounds can vote no, and if the
> procedural issue really is so important, there is a recourse available for
> this.  Having to fight these kinds of battles over my work to improve the
> language is needlessly taxing, and this too is a form of unhealthy environment.

Part of a healthy environment for me is that I can be sure that others 
are following the agreed rules that are intended to give everyone the 
opportunity to carefully digest and think about changes affecting the 
language and to plan and prioritize their participation in the RFC 
process with regard to other tasks, both related to the language 
development and day-to-day real life duties.

Therefore it is important to me that the proper process is upheld for 
any change, no matter or big or small and I disagree that this is a 
“minor” procedural disagreement. If we only followed the policy when it 
is convenient and ignored it when it's not, we would not need to have a 
policy. Policies (and contracts) are agreed-on to set expectations and 
help make decisions in future cases of disagreement.

It is especially important to me that the regular contributors carefully 
follow the policies, since the behavior of those set an example for new 
contributors and the folks silently following along. In the past few 
weeks leading up to PHP 8.5's feature freeze there were several RFCs 
that I felt were in a grey area with regard to the current accepted 
practice / gentleman's agreement of doing RFCs, several of those from 
less-experienced or first-time contributors. They were not in direct 
violation of the written policy, though. I believe this one was and 
that's why I was speaking up.

I already had planned to do a policy RFC after my vacation to clarify 
the language and bring the policy up to date with the current accepted 
practice of doing things. I'm happy to further discuss the topic as part 
of that policy RFC then.

And to be clear: I'm favor of the “Casting out of range floats to int” 
proposal from a technical point of view and I agree that it's a clearly 
positive change. But I disagree that it is a “minor change” that doesn't 
warrant the same treatment as any other RFC.

Best regards
Tim Düsterhus