On Monday, 28 July 2025 at 16:22, Tim Düsterhus <t...@bastelstu.be> wrote:
> Am 2025-07-28 16:23, schrieb Gina P. Banyard: > > > As I am aware it is in bad taste to shove something new into such a > > proposal minutes before starting the vote, > > I'll postpone the vote for a few hours so that at least some people > > can see and raise objections. > > > For visibility: I object. See sibling email. Said sibling email: On Monday, 28 July 2025 at 15:31, Tim Düsterhus <t...@bastelstu.be> wrote: > Am 2025-07-28 16:20, schrieb Gina P. Banyard: > > > I've added a whole new section that addresses this, as out of range > > casts are completely whack. > > See: > > https://wiki.php.net/rfc/warnings-php-8-5#casting_out_of_range_floats_to_int > > > This effectively is another “Primary Vote” for an entirely new proposal > and as such requires 2 weeks of discussion. If you want to vote on this > RFC for PHP 8.5, you'll need to drop that section again. > > Best regards > Tim Düsterhus I am going to bring the RFC in its totality to a vote later today. You can consider this a new primary vote, vote no, and even argue for this part of the RFC to be rendered void regardless of the result. Or just incentivize people to vote no, so you don't even need to deal with this. Claude raised the edge case 2 days ago, and I found the extent of it to be even larger than expected. I thought that it would be better to create a whole new section rather than twisting the existing "NAN" warning proposal to fit the new constraints, but apparently I should have done this instead and changed all instances of "NAN" to "non-representable floats". 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. Using "process violations" to prevent PHP from being less shit when an additional edge case of a proposal is found, for IDK 5 additional years impacting countless developers, old and new, is something that I find infuriating. And I guess this truly showcases how broken and infuriating our RFC process can be, especially around feature freeze. Moreover, if we are going to do legalese, the only thing our policy actual states are the following: [1] > There'd be a minimum of 2 weeks between when an RFC that touches the language > is brought up on this list and when it's voted on is required. [...] > For procedural reasons, multiple RFCs may be combined into one, in which case > there may be multiple primary votes. > Combining multiple RFCs into one does not allow turning a primary vote into a > secondary vote. There is no mention of the content of an RFC needing to be "identical" for 2 weeks. Thus, I can, and seemingly I really should have, edited the "NAN" proposal (or any of the other ones) to include this and then make it a secondary vote "should this be extended to non-representable floats or not". Therefore, if there is even more push back, I will proceed that way, so the grouping only has 4 "main proposals" rather than 5. Sincerely, Gina P. Banyard [1] https://github.com/php/policies/blob/main/feature-proposals.rst
