On Sunday, 13 April 2025 at 22:07, Jorg Sowa <[email protected]> wrote:
> Thank you all for the feedback on the topic of BC breaks in argument validation https://news-web.php.net/php.internals/126706
>
> I have collected all concerns, prepared an RFC for this change, and I'm opening discussion
> on its content: https://wiki.php.net/rfc/minor-version-compatibility
>
> Since this touches on the broader topic of release policy and BC expectations, I’d also like
> to open the door for related improvements. Rowan raised several valid points that highlight the need
> for clearer communication and expectations around minor version changes. If the community feels
> it's appropriate, I’m happy to include these suggestions in the voting. The more clearly BC
> policy is defined, the less time we’ll need to spend on debating individual cases in the future.
>
> Rowan’s suggestions included examples like:
>
>> Maybe we could work on some criteria that could be applied (and publicised to users) about
>> what is and isn't allowed in minor versions.
>> For instance:
>>
>> -
>>
>> Code that already causes fatal behaviour might cause different fatal behaviour (e.g.
>> throwing an Error instead of raising an E_ERROR)
>>
>> -
>>
>> Code that directly violates documented types might start throwing TypeError
>>
>> -
>>
>> Code that previously returned null for invalid inputs might start throwing ValueError
I fundamentally reject the concept of this RFC to restrict our ability to do input validation.
Emitting an E_DEPRECATED for invalid inputs remains utter nonsense.
And this policy would severely impact incremental improvements to the language.
Moreover, I have yet to actually be shown a lack of "consensus" on this issue by the core
dev team.
The following PR [1] was opened on the day this RFC was published (April 13), was reviewed and
approved by 2 different core developers that have *not* participated in the previous discussion
thread, and merged on the 15th.
This PR checks that the input string does not contain any NUL bytes, and if yes, now throws the
standard ValueError.
A similar PR [2] was open by yet another, different, core developer, reviewed, and merged on April
22.
This, to me, indicates a clear consensus within the core dev team that these sorts of BC breaks are
accepted and routine.
Let's go back to how this policy would impact incremental improvements to PHP.
And I will take one of your *own* prior RFCs as an example.
In this RFC, you point to the following PR [3] titled "round(): Validate the rounding
mode", which was opened and merged about 2-3 weeks after you announced your RFC "Add 4 new
rounding modes to round() function". [4][5]
That RFC states the following:
> Backward Incompatible Changes
> None
And this has been the case since the creation of the document by yourself, to the latest edit. [6]
According to the policy you are suggesting, the above statement is just plain false.
Because introducing *new* modes when the existing ones are not validates is a BC break, because if
someone used the value of what would become e.g. PHP_ROUND_AWAY_FROM_ZERO they would have a change
in behaviour (as it would stop rounding like PHP_ROUND_HALF_UP).
You could argue that this point is moot as we ended up not introducing new constants and use an enum
for the new rounding modes. [7]
However, you were also against removing the newly introduced constants and to have the new rounding
mode only be exposed via the new enum. [8]
The only reason you could state that there were no BC breaks in that RFC, was that validating the
input mode is something we could do.
Accordingly, if this was not permitted, the only way to add new rounding modes would have to have
been to wait for PHP 9.
Something that is completely ridiculous.
Validating the *value* of an argument is no different from validating the *type* of an argument
passed to a function.
If PHP had a more advanced type system that include dependent types (which are types that depend on
the *value*) then those ValueErrors would *be* TypeErrors.
And this is *not* a foreign concept to many people within the PHP community that use static analysis
tools, as non-empty-array, non-zero-int, positive-int,
non-empty-string, numeric-string, and many others are limited cases of
dependent types. [9][10]
So attempting to create a policy where somehow introducing TypeErrors is OK but not ValueErrors is
completely nonsensical.
I will repeat this once again, but error-ing on *invalid* inputs entered by the developer is an
*advantage*.
I cannot comprehend the motivation to let users ship buggy code into production, that might end up
hard to debug.
We throw Errors on non-existent constants, functions, classes, etc. for a reason.
As such, if this policy does get accepted, I will start to severely reduce my contributions to the
project.
As it would be a clear sign to me that what people want from the project is something that I find
completely nonsensical and thus I should direct my energy and time to something more inline with my
own design beliefs.
Sincerely,
Gina P. Banyard
>
[1] https://github.com/php/php-src/pull/18320
[2] https://github.com/php/php-src/pull/18365
[3] https://github.com/php/php-src/pull/12252
[4] https://wiki.php.net/rfc/new_rounding_modes_to_round_function
[5] https://externals.io/message/120971
[6] https://wiki.php.net/rfc/new_rounding_modes_to_round_function?do=diff&rev2%5B0%5D=1693437057&rev2%5B1%5D=1730760929&difftype=sidebyside
[7] https://wiki.php.net/rfc/correctly_name_the_rounding_mode_and_make_it_an_enum
[8] https://externals.io/message/123472#123486
[9] https://phpstan.org/writing-php-code/phpdoc-types#integer-ranges
[10] https://psalm.dev/docs/annotating_code/type_syntax/array_types/#non-empty-array