On Sunday, 13 April 2025 at 22:07, Jorg Sowa <jorg.s...@gmail.com> 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
