On Monday, 28 July 2025 at 19:08, Ilija Tovilo <tovilo.il...@gmail.com> wrote:
> Hi Gina > > On Mon, Jul 28, 2025 at 7:15 PM Gina P. Banyard intern...@gpb.moe wrote: > > > I find it increasingly frustrating that trying to make PHP not be > > completely insane is met with resistance at every turn, > > and I'm once more at the stage that I really should stop wasting my time > > and caring about PHP and do something better with my life. > > > I appreciate all the work you have put into PHP. However, I don't > think threatening to quit PHP over disagreements (which is not the > first time either, I believe) creates a healthy environment for > discussion. Internals should not fear voicing their concerns. I also > believe the concern is not technical, and this would have no trouble > passing in the next version. > > Ilija Hi Ilija, Let's take a breath and review what's going on. My original proposal was to warn when type juggling NAN, as this is unexpected behaviour, and this was discussed on the mailing list. Then, just this Saturday, Claude pointed out that INF also has this problem (casting INF to int 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, however, so instead I added the new proposal to make it clear this is a closely related but even more narrow change. 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 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). 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 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. Best regards, Gina P. Banyard
