Hello internals,
Similar to the mass deprecation RFC, I would like to propose the addition of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5
I am expecting these 4 sub-proposals to be mostly uncontroversial,
other than possibly, the "Using offsets on non-container values in isset()/empty()" one.
As this is intended to land in PHP 8.5 the discussion will last 2 weeks and voting will commence on Monday the 28th of July 2025.
Best regards,
Gina P. Banyard
Hi Gina,
Le lun. 14 juil. 2025 à 18:22, Gina P. Banyard internals@gpb.moe a écrit :
Hello internals,
Similar to the mass deprecation RFC, I would like to propose the addition
of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5I am expecting these 4 sub-proposals to be mostly uncontroversial,
other than possibly, the "Using offsets on non-container values in
isset()/empty()" one.As this is intended to land in PHP 8.5 the discussion will last 2 weeks
and voting will commence on Monday the 28th of July 2025.
Why warnings and not deprecations if the plan is to Error on PHP 9?
As you might know, it's very common to turn warnings into exceptions in
userland so this will break apps for sure. Deprecations don't if properly
handled. Please trigger deprecations instead.
About destructuring non-array values, null is a very common case that
allows writing nice readable code.
Here is a dummy example:
if ([$a, $b] = $array[$key] ?? null) { /.../ }
Turning this into a warning will have a significant impact for sure. Even a
deprecation would just make the language a bit less pleasant to use without
any real benefit, unless I missed any other rationale.
The rest makes sense to me, thanks for spotting these cases.
Nicolas
Hi Gina,
Le lun. 14 juil. 2025 à 18:22, Gina P. Banyard internals@gpb.moe a écrit :
Hello internals,
Similar to the mass deprecation RFC, I would like to propose the addition of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5I am expecting these 4 sub-proposals to be mostly uncontroversial,
other than possibly, the "Using offsets on non-container values in isset()/empty()" one.As this is intended to land in PHP 8.5 the discussion will last 2 weeks and voting will commence on Monday the 28th of July 2025.
Why warnings and not deprecations if the plan is to Error on PHP 9?
As you might know, it's very common to turn warnings into exceptions in userland so this will break apps for sure. Deprecations don't if properly handled. Please trigger deprecations instead.
Because those point to bugs, rather than usage of a valid feature.
As such a warning is appropriate, and people being made aware more quickly about it by an error handler that promotes warnings is the behaviour I want.
About destructuring non-array values, null is a very common case that allows writing nice readable code.
Here is a dummy example:
if ([$a, $b] = $array[$key] ?? null) { /.../ }Turning this into a warning will have a significant impact for sure. Even a deprecation would just make the language a bit less pleasant to use without any real benefit, unless I missed any other rationale.
If you want to provide default values, then surely:
if ([$a, $b] = $array[$key] ?? [null, null])
makes more sense, especially as this allows you to choice different defaults for $a and $b.
Best regards,
Gina P. Banyard
Le ven. 18 juil. 2025 à 14:54, Gina P. Banyard internals@gpb.moe a écrit :
On Tuesday, 15 July 2025 at 18:16, Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:Hi Gina,
Le lun. 14 juil. 2025 à 18:22, Gina P. Banyard internals@gpb.moe a
écrit :Hello internals,
Similar to the mass deprecation RFC, I would like to propose the addition
of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5I am expecting these 4 sub-proposals to be mostly uncontroversial,
other than possibly, the "Using offsets on non-container values in
isset()/empty()" one.As this is intended to land in PHP 8.5 the discussion will last 2 weeks
and voting will commence on Monday the 28th of July 2025.Why warnings and not deprecations if the plan is to Error on PHP 9?
As you might know, it's very common to turn warnings into exceptions in
userland so this will break apps for sure. Deprecations don't if properly
handled. Please trigger deprecations instead.Because those point to bugs, rather than usage of a valid feature.
As such a warning is appropriate, and people being made aware more quickly
about it by an error handler that promotes warnings is the behaviour I want.
Then obviously this argument doesn't apply to destructuring non-array
values.
This makes me doubtful about the others. A deprecation would be more
appropriate to me.
About destructuring non-array values, null is a very common case that
allows writing nice readable code.
Here is a dummy example:
if ([$a, $b] = $array[$key] ?? null) { /.../ }Turning this into a warning will have a significant impact for sure. Even
a deprecation would just make the language a bit less pleasant to use
without any real benefit, unless I missed any other rationale.If you want to provide default values, then surely:
if ([$a, $b] = $array[$key] ?? [null, null])
makes more sense, especially as this allows you to choice different
defaults for $a and $b.
That's broken, the "if" will always be truthy using this style.
There's nothing wrong with the current code. It doesn't need to be
deprecated.
I'd say the same when false is returned BTW.
For other values, I'm not aware of any use cases so might be fine
deprecating.
Nicolas
Hi
Am 2025-07-23 13:30, schrieb Nicolas Grekas:
About destructuring non-array values, null is a very common case that
allows writing nice readable code.
Here is a dummy example:
if ([$a, $b] = $array[$key] ?? null) { /.../ }Turning this into a warning will have a significant impact for sure.
Even
a deprecation would just make the language a bit less pleasant to use
without any real benefit, unless I missed any other rationale.If you want to provide default values, then surely:
if ([$a, $b] = $array[$key] ?? [null, null])
makes more sense, especially as this allows you to choice different
defaults for $a and $b.That's broken, the "if" will always be truthy using this style.
There's nothing wrong with the current code. It doesn't need to be
deprecated.
It seems appropriate to mention the previous (declined) “Destructuring
Coalesce” RFC at this point:
https://wiki.php.net/rfc/destructuring_coalesce. Perhaps it might make
sense to revisit that one?
Best regards
Tim Düsterhus
Hi
Am 2025-07-23 13:30, schrieb Nicolas Grekas:
About destructuring non-array values, null is a very common case that
allows writing nice readable code.
Here is a dummy example:
if ([$a, $b] = $array[$key] ?? null) { /.../ }Turning this into a warning will have a significant impact for sure.
Even
a deprecation would just make the language a bit less pleasant to use
without any real benefit, unless I missed any other rationale.If you want to provide default values, then surely:
if ([$a, $b] = $array[$key] ?? [null, null])
makes more sense, especially as this allows you to choice different
defaults for $a and $b.That's broken, the "if" will always be truthy using this style.
There's nothing wrong with the current code. It doesn't need to be
deprecated.It seems appropriate to mention the previous (declined) “Destructuring
Coalesce” RFC at this point:
https://wiki.php.net/rfc/destructuring_coalesce. Perhaps it might make
sense to revisit that one?Best regards
Tim Düsterhus
I've dropped warning null from the proposal, and mentioned the declined RFC.
Best regards,
Gina P. Banyard
Hello internals,
Similar to the mass deprecation RFC, I would like to propose the addition of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5I am expecting these 4 sub-proposals to be mostly uncontroversial,
other than possibly, the "Using offsets on non-container values in isset()/empty()" one.As this is intended to land in PHP 8.5 the discussion will last 2 weeks and voting will commence on Monday the 28th of July 2025.
Best regards,
Gina P. Banyard
Hi Gina, I feel like destructuring null should not be the same warning as other types since null auto-vivicates? to [] (an empty array). Instead, it should provide the same warning as https://3v4l.org/8QPiD.
— Rob
Hi Gina, I feel like destructuring
nullshould not be the same warning as other types since null auto-vivicates? to [] (an empty array). Instead, it should provide the same warning as https://3v4l.org/8QPiD.
Autovivification is only about write operations, not read.
Therefore, I don't really understand that argument because destructuring is a read operation, and reading an offset on null emits:
Trying to access array offset on null
(see https://3v4l.org/sMkCD#vnull)
Which is the same wording as the warning when reading an offset on a scalar:
Warning: Trying to access array offset on int
As such, they should have the same warning here as well.
Best regards,
Gina P. Banyard
Similar to the mass deprecation RFC, I would like to propose the
addition of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5I am expecting these 4 sub-proposals to be mostly uncontroversial,
other than possibly, the "Using offsets on non-container values in
isset()/empty()" one.
That one seems to miss examples in the RFC as well. It might be useful
to add those.
Having said that, I am unsure as why I would want to see a way how
isset/empty behave in either the "using offsets on non-container values"
or "using invalid offset types" cases. These language constructs are
often used as a guard in (albeit likely older code), and hence, this
now throwing a warning doesn't really add anything for the developer.
I'm also curious to know whether you or somebody else has checked what
the effect of this change on existing code bases would be?
cheers,
Derick
--
https://derickrethans.nl | https://xdebug.org | https://dram.io
Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support
mastodon: @derickr@phpc.social @xdebug@phpc.social
Le 14 juil. 2025 à 18:23, Gina P. Banyard internals@gpb.moe a écrit :
Hello internals,Similar to the mass deprecation RFC, I would like to propose the addition of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5I am expecting these 4 sub-proposals to be mostly uncontroversial,
other than possibly, the "Using offsets on non-container values in isset()/empty()" one.As this is intended to land in PHP 8.5 the discussion will last 2 weeks and voting will commence on Monday the 28th of July 2025.
Best regards,
Gina P. Banyard
Hi,
About “ coercing NAN to other types”:
- The result of
(string) NANseems reasonable to me and don’t need warning. - I agree that
(int) NANdoes not make much sense, but if we warn on that, we should also warn on(int) INF, which makes even less sense (I expected(int) INFto yieldPHP_INT_MAX, but it yields0). - I strongly think that this should be a deprecation, not a warning. There may be correct programs that rely on the fact that explicit coercing from a random scalar to another scalar type is infallible (as it is the case today), although not expecting a specific value from a buggy input (GIGO principle).
—Claude
Le 14 juil. 2025 à 18:23, Gina P. Banyard internals@gpb.moe a écrit :
Hello internals,Similar to the mass deprecation RFC, I would like to propose the addition of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5
- The result of
(string) NANseems reasonable to me and don’t need warning.- I agree that
(int) NANdoes not make much sense, but if we warn on that, we should also warn on(int) INF, which makes even less sense (I expected(int) INFto yieldPHP_INT_MAX, but it yields0).
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
Best regards,
Gina P. Banyard
Hi
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
Hello internals,
Similar to the mass deprecation RFC, I would like to propose the addition of a few warnings in certain situations:
https://wiki.php.net/rfc/warnings-php-8-5I am expecting these 4 sub-proposals to be mostly uncontroversial,
other than possibly, the "Using offsets on non-container values in isset()/empty()" one.As this is intended to land in PHP 8.5 the discussion will last 2 weeks and voting will commence on Monday the 28th of July 2025.
As Claude pointed out a major pitfall, that I wasn't even aware of, I added a new proposal to the RFC:
"Casting out of range floats to int"
https://wiki.php.net/rfc/warnings-php-8-5#casting_out_of_range_floats_to_int
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.
Best regards,
Gina P. Banyard
Hi
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.
Best regards
Tim Düsterhus
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:
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_intThis 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
Hi Gina
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 Gina
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
Hi Gina
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 thatINFalso has this problem (castingINFto 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
I am not sure that (int)"INF" or (int)"NAN" is misbehaving.
(int)"Password" also produces0, 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.
This is about INF and NAN, the float values, not the strings "INF" and
"NAN".
https://3v4l.org/fAFn3
-- Alex
__
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.This is about
INFand NAN, the float values, not the strings "INF" and "NAN".
https://3v4l.org/fAFn3-- Alex
Thanks Alex, I missed that nuance!
— Rob
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.
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
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:
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üsterhusI 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.
I guess this is a bit of a loop hole in the process but essentially I think
you have got right to add such last minute changes to the RFC and open vote
next day (or even next minute) if you want. The current policy doesn't
really consider those multi vote RFC's but technically it's still a single
RFC which is announced on internal just once and the date of announcement
on internals is what matters. If we should change those rules is really for
another discussion though.
Jakub
Warning: non-representable float was cast to int
Will this have a significant performance impact?
Warning: Cannot access offset of type TYPE on string
Why is this a warning and not a TypeError? If the goal is to make the
behavior identical to null coalesce operator then having a warning seems to
stray away from it.