The vote was on accepting php/policies PR #27. It passed 26 to 5, with 3 abstaining, clearing the two-thirds majority it needed. Voting closed on April 4, 2026.
Accepted
Exempt input type and value validation from BC Break policy
Exempts new TypeError and ValueError input checks, and reworded error messages, from PHP's backward compatibility break policy.
Accept php/policies PR #27?
26 Yes
5 No
3 abstain
84% approval
This poll has closed.
Summary
PHP has a policy that defines what counts as a backward compatibility (BC) break, meaning a change that could stop existing code from working. This RFC from Gina Peter Banyard adds a clear exception to that policy: adding validation to a function's inputs, and rewording error messages, no longer counts as a break.
Why change it
PHP ships with many bundled extensions, like ext/curl and ext/snmp, and some of them do very little input validation. A few don't even check types.
Adding those checks used to be routine cleanup work. Lately, people have asked for a full RFC each time, and the RFC says that stretches a simple cleanup out to weeks and makes things harder for new contributors.
Skipping validation carries its own risk. Say a function accepts flags with the values 1, 2 and 4, and you pass 8 by mistake. Nothing happens. Later, the extension adds a real flag with the value 8, and now your code quietly does something new. PHP's policy says breaking changes should be obvious, not silent.
The RFC also notes that missing input validation has caused security bugs more than once, and those fixes added thrown errors in stable releases anyway.
What the policy allows
Under the new rule, PHP can make these changes without a separate RFC:
- Reword warning messages and exception messages
- Throw a
TypeErrorwhen an input, or a value inside an input array, has the wrong type - Throw a
ValueErrorwhen an input is out of range, empty, contains null bytes, uses flags that don't exist, or has the wrong kind of array keys - Promote warnings to a
TypeError - Promote warnings to a
ValueError, but only when the problem is easy for the caller to avoid
The RFC says this list isn't exhaustive.
What it means for you
If your code passes the wrong types or invalid values to a PHP function, a future release may throw an error instead of carrying on. If you match on the exact text of an error message, that text may change. Code that passes valid input shouldn't notice anything.