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
