[RFC] [Discussion] Minor version compatibility

Hey Jorg,

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

Let me address some parts of the RFC:

• The secondary vote #1 requires the same handling for everything. I
  don't think that's a wise choice.
    There may be cases where keeping an E_WARNING (not E_DEPRECATED
  though) may be acceptable.
    There may be recently (e.g. last minor) introduced APIs, which, by
  oversight, accept unexpected inputs. It may be decided that it would be
  too much of a compatibility break to "fix" this in a bugfix version.
  However, it should be possible to decide to fix this straight ahead in
  the next minor, rather than waiting for the next major. Especially for
  recently introduced features, having deprecation periods of possibly 4
  years, when they were only introduced the year before, is a bit excessive.

• The secondary vote #2 requires that you either select E_DEPRECATED or
  E_WARNING. That's not right. E_DEPRECATED may be a precursor to E_WARNING.
    There's no silver bullet on what exactly is to be chosen.
  E_DEPRECATED is for something which will change, but is generally not
  problematic in existing code. E_WARNING is for something which may
  change and is probably problematic in existing code.
    This though means that there will be cases where there's ambiguity.
  That's fine. Reach a soft consensus and then go ahead with that.

I don't fundamentally disagree with the attempt to codify something
here, but ultimately the PHP language does and will continue to profit
from some flexibility in these regards.

I think, with the choices, we've actually ended up making in the last 12
years (essentially since PHP 5.5), users haven't been surprised too much.
At least also anecdotally from my experience - upgrading old code is
perfectly fine to do with last minor -> first minor -> last minor -> ...
upgrades.
New code is not fine to do such major jumps. Semantics of code using
brand new features is improved sometimes. Bugs are fixed. Things end up
slightly different. That's fine though. If you want to live on the edge,
that's the price you pay for this. Being able to rectify freshly
introduced mistakes and inaccuracies quickly is important for the health
of the language.

Please, while it's sane sounding, let's not codify too much of
black-and-white policies.

Thank you,

Bob

Hi,

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

This looks a bit too generic to me and it might significantly differ based
on use case as Bob noted. I think we should leave some flexibility and
rather add rules for specific issues where we need some defined approach.
In this case it is handling of errors for cases where only constants are
documented.

Kind regards

Jakub

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