On Tue, Jul 29, 2025, at 11:01, Gina P. Banyard wrote: > 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
I am not sure that (int)"INF" or (int)"NAN" is misbehaving. (int)"Password" also produces `0`, and these are strings. If we had the time to discuss it properly, I would argue that simply warning when casting a string to int is the most sensible thing, just like we get an error when coercing a string to int, which is more consistent across the language than just special casing some strings. — Rob
