Hello internals,
I would like to propose a short policy RFC to formally exempt input type and value validation from our BC Break policy.
The current wording of the policy already permits us to add validation of inputs, but recently any such changes have been asked to submit an RFC instead.
We believe that requiring an RFC for this type of change is detrimental and adds unnecessary friction for routine maintenance activity and new contributors.
RFC: https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-policy
Best regards,
Gina P. Banyard
Am 02.03.2026 um 14:13 schrieb Gina P. Banyard internals@gpb.moe:
I would like to propose a short policy RFC to formally exempt input type and value validation from our BC Break policy.
The current wording of the policy already permits us to add validation of inputs, but recently any such changes have been asked to submit an RFC instead.
We believe that requiring an RFC for this type of change is detrimental and adds unnecessary friction for routine maintenance activity and new contributors.RFC: https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-policy
Playing my favourite broken record:
Can we please state that additions of Exceptions should (in most cases) go through an E_WARNING phase to allow a time window to fix code before changing the behaviour?
I'm fine with not needing an RFC for such changes as long as the migration process is being respected.
Regards,
- Chris
Hi
Playing my favourite broken record:
Can we please state that additions of Exceptions should (in most cases) go through anE_WARNINGphase to allow a time window to fix code before changing the behaviour?
“Not passing invalid values” is perfectly backwards compatible. Folks
can just fix their code before upgrading their production deployment to
the new PHP version, e.g. by trying out the new PHP version in a staging
system or running CI for both the old and new PHP version.
In practice an E_WARNING is no less breaking than going straight to an
Error, because:
The common frameworks include error handlers that just convert any
warning and notice to an Exception.
The code is already broken, because it relies on unspecified behavior.
The error would just making the user aware that the code is very likely
not doing what it appears to be doing based on the input values passed
to a function.
To give a concrete example: The sort() function has a second parameter
int $flags = SORT_REGULAR. So clearly I can pass one of the SORT_*
constants to it. Let's see which ones we have:
foreach (get_defined_constants() as $constant => $value) {
if (str_starts_with($constant, 'SORT_')) {
echo $constant, ": ", $value, PHP_EOL;
}
}
This prints:
SORT_ASC: 4
SORT_DESC: 3
SORT_REGULAR: 0
SORT_NUMERIC: 1
SORT_STRING: 2
SORT_LOCALE_STRING: 5
SORT_NATURAL: 6
SORT_FLAG_CASE: 8
Great! Let's sort an array in descending order:
$array = [1, 5, 3];
sort($array, SORT_DESC);
echo implode(", ", $array), PHP_EOL;
This code clearly prints 5, 3, 1, since SORT_DESC is a SORT_*
constant that is accepted by sort() and DESC is a common abbreviation
for descending, right?
Going through an E_WARNING would add maintainer busywork and complicate
the php-src codebase for no real gain.
Best regards
Tim Düsterhus
Am 02.03.2026 um 20:12 schrieb Tim Düsterhus tim@bastelstu.be:
Playing my favourite broken record:
Can we please state that additions of Exceptions should (in most cases) go through anE_WARNINGphase to allow a time window to fix code before changing the behaviour?“Not passing invalid values” is perfectly backwards compatible. Folks can just fix their code before upgrading their production deployment to the new PHP version, e.g. by trying out the new PHP version in a staging system or running CI for both the old and new PHP version.
- Not everybody has access to a staging system, e.g. people running stuff on hosting services.
- As a hoster I'd rather have a phase where my customers get warnings instead of errors, creates less emergency support load.
In practice an
E_WARNINGis no less breaking than going straight to an Error, because:
- The common frameworks include error handlers that just convert any warning and notice to an Exception.
So in that sense there is also no advantage to NOT having a warning phase for those people.
But people treating E_WARNING different from Exceptions (which is probably the exact people whose code breaks with an immediate Exception) do have a time window to fix things.
- The code is already broken, because it relies on unspecified behavior. The error would just making the user aware that the code is very likely not doing what it appears to be doing based on the input values passed to a function.
It can easily do something valid and ignore the extra bits (pun kind of intended), see
mkdir("foo", 070777);
which passes extra bits with are ignored but the application was behaving in a completely deterministic and valid way.
Going through an
E_WARNINGwould add maintainer busywork and complicate the php-src codebase for no real gain.
We've been over this before:
If people really feel that the additional burden to change the code twice then I'd be happy to volunteer providing a small helper function/macro to generate an E_WARNING and either (the more aggressive approach) switch to an exception once a certain PHP version is reached or (probably the more flexible way) issue a compile time warning/error informing the maintainer to switch the warning to an Exception.
The most simplistic version of this is a FIXME comment annotated with a version number. Easy to grep, easy to trigger automatic alerts about once the specified version is reached, but it can also be something more sophisticated..
One way or the other could also be integrated into the CI/CD system.
Our main disagreement is about the "no real gain" part as it IMHO targets the long tail of PHP code / developers out there not using full-fledged frameworks and dev environments or running legacy software on hosting services.
I am very much in favor of making things easy for the code developers but I am of the strong believe that it can be done in a good way for developers.
Regards,
- Chris
Am 02.03.2026 um 20:12 schrieb Tim Düsterhus tim@bastelstu.be:
Playing my favourite broken record:
Can we please state that additions of Exceptions should (in most cases) go through anE_WARNINGphase to allow a time window to fix code before changing the behaviour?“Not passing invalid values” is perfectly backwards compatible. Folks can just fix their code before upgrading their production deployment to the new PHP version, e.g. by trying out the new PHP version in a staging system or running CI for both the old and new PHP version.
- Not everybody has access to a staging system, e.g. people running stuff on hosting services.
- As a hoster I'd rather have a phase where my customers get warnings instead of errors, creates less emergency support load.
In practice an
E_WARNINGis no less breaking than going straight to an Error, because:
- The common frameworks include error handlers that just convert any warning and notice to an Exception.
So in that sense there is also no advantage to NOT having a warning phase for those people.
But people treatingE_WARNINGdifferent from Exceptions (which is probably the exact people whose code breaks with an immediate Exception) do have a time window to fix things.
- The code is already broken, because it relies on unspecified behavior. The error would just making the user aware that the code is very likely not doing what it appears to be doing based on the input values passed to a function.
It can easily do something valid and ignore the extra bits (pun kind of intended), see
mkdir("foo", 070777);
which passes extra bits with are ignored but the application was behaving in a completely deterministic and valid way.Going through an
E_WARNINGwould add maintainer busywork and complicate the php-src codebase for no real gain.We've been over this before:
If people really feel that the additional burden to change the code twice then I'd be happy to volunteer providing a small helper function/macro to generate anE_WARNINGand either (the more aggressive approach) switch to an exception once a certain PHP version is reached or (probably the more flexible way) issue a compile time warning/error informing the maintainer to switch the warning to an Exception.
The most simplistic version of this is a FIXME comment annotated with a version number. Easy to grep, easy to trigger automatic alerts about once the specified version is reached, but it can also be something more sophisticated..
One way or the other could also be integrated into the CI/CD system.Our main disagreement is about the "no real gain" part as it IMHO targets the long tail of PHP code / developers out there not using full-fledged frameworks and dev environments or running legacy software on hosting services.
I am very much in favor of making things easy for the code developers but I am of the strong believe that it can be done in a good way for developers.
I don't see how going through an E_WARNING phase is helpful, rather I see it as detrimental.
Foremost, what is the behaviour of introducing a warning?
Do we exit early and return false?
Or do we just warn and continue to use a possible default or nonsensical value?
AFAIK every time a warning got introduced it followed the first approach, so this doesn't seem to address the concern of giving developers more time.
However, if we do continue using the prior behaviour then we haven't solved the concern in the slightest.
As it may be a warning for one PHP version and in the next PHP version the extension supports a new flag which removes the warning for that value, leading back to a silent BC break if the warning wasn't addressed.
Another technical aspect is that warnings allows userland code to run and change the state of the VM and extension in unexpected way (we have countless fuzzying reports about this) an issue that does not exist with Exceptions.
Then comes the topic about how long should it be a warning? Until the next major? A single release cycle? I don't want warning promotion to become the same exhausting discussion that deprecation duration already is.
I have no idea how you handle hosting, but when I used shared hosting in the past I would never have anyone tell me that my code was producing warnings or notices.
And even the one website I manage for someone which is on OVH shared hosting I can still select a PHP version (heck even downgrading to 5.4 for some reason).
So I'm struggling to see how for the average end user this is impacting them?
And if you do just bump the PHP version for them, I'm not sure what's the difference between having an Error immediately or producing warnings for X years before throwing an Error and breaking
Best regards,
Gina P. Banyard
Am 02.03.2026 um 20:12 schrieb Tim Düsterhus tim@bastelstu.be:
Playing my favourite broken record:
Can we please state that additions of Exceptions should (in most cases) go through anE_WARNINGphase to allow a time window to fix code before changing the behaviour?“Not passing invalid values” is perfectly backwards compatible. Folks can just fix their code before upgrading their production deployment to the new PHP version, e.g. by trying out the new PHP version in a staging system or running CI for both the old and new PHP version.
- Not everybody has access to a staging system, e.g. people running stuff on hosting services.
- As a hoster I'd rather have a phase where my customers get warnings instead of errors, creates less emergency support load.
In practice an
E_WARNINGis no less breaking than going straight to an Error, because:
- The common frameworks include error handlers that just convert any warning and notice to an Exception.
So in that sense there is also no advantage to NOT having a warning phase for those people.
But people treatingE_WARNINGdifferent from Exceptions (which is probably the exact people whose code breaks with an immediate Exception) do have a time window to fix things.
- The code is already broken, because it relies on unspecified behavior. The error would just making the user aware that the code is very likely not doing what it appears to be doing based on the input values passed to a function.
It can easily do something valid and ignore the extra bits (pun kind of intended), see
mkdir("foo", 070777);
which passes extra bits with are ignored but the application was behaving in a completely deterministic and valid way.Going through an
E_WARNINGwould add maintainer busywork and complicate the php-src codebase for no real gain.We've been over this before:
If people really feel that the additional burden to change the code twice then I'd be happy to volunteer providing a small helper function/macro to generate anE_WARNINGand either (the more aggressive approach) switch to an exception once a certain PHP version is reached or (probably the more flexible way) issue a compile time warning/error informing the maintainer to switch the warning to an Exception.
The most simplistic version of this is a FIXME comment annotated with a version number. Easy to grep, easy to trigger automatic alerts about once the specified version is reached, but it can also be something more sophisticated..
One way or the other could also be integrated into the CI/CD system.Our main disagreement is about the "no real gain" part as it IMHO targets the long tail of PHP code / developers out there not using full-fledged frameworks and dev environments or running legacy software on hosting services.
I am very much in favor of making things easy for the code developers but I am of the strong believe that it can be done in a good way for developers.
I don't see how going through an
E_WARNINGphase is helpful, rather I see it as detrimental.
Foremost, what is the behaviour of introducing a warning?
Do we exit early and return false?
Or do we just warn and continue to use a possible default or nonsensical value?
AFAIK every time a warning got introduced it followed the first approach, so this doesn't seem to address the concern of giving developers more time.
However, if we do continue using the prior behaviour then we haven't solved the concern in the slightest.
As it may be a warning for one PHP version and in the next PHP version the extension supports a new flag which removes the warning for that value, leading back to a silent BC break if the warning wasn't addressed.Another technical aspect is that warnings allows userland code to run and change the state of the VM and extension in unexpected way (we have countless fuzzying reports about this) an issue that does not exist with Exceptions.
Then comes the topic about how long should it be a warning? Until the next major? A single release cycle? I don't want warning promotion to become the same exhausting discussion that deprecation duration already is.
I have no idea how you handle hosting, but when I used shared hosting in the past I would never have anyone tell me that my code was producing warnings or notices.
And even the one website I manage for someone which is on OVH shared hosting I can still select a PHP version (heck even downgrading to 5.4 for some reason).
So I'm struggling to see how for the average end user this is impacting them?
And if you do just bump the PHP version for them, I'm not sure what's the difference between having an Error immediately or producing warnings for X years before throwing an Error and breakingBest regards,
Gina P. Banyard
I am in favour of exempting the validation errors from requiring RFCs,
and as Gina, I do not believe that warnings are useful. I don't like
that warnings even exist in the PHP language. I can see the case that
you don't want to break a running application by upgrading the PHP
version, but it can happen regardless. Minor PHP releases can contain
minor breaking changes and each time someone upgrades PHP, they should
run their test suite and verify that the application still works the
same as before. Whether we introduce a Warning or ValueError, it will
be caught during the upgrade process and fixed. It may even help avoid
nasty bugs if the application stops on invalid input; something which
could go unnoticed if it were only a warning.
I am, however, concerned about one thing. If we don't require RFCs
there may be situations when a contentious validation is introduced.
For example, many validations can be implemented in such a way that
they don't cause additional performance loss, but let's say someone
decides that validating the value provides more benefit than the
performance cost. Without RFC, the community cannot share their
feedback, and one person's opinion wins. But if the function is used
with the correct values 99.99% of the time and it's used in the hot
code, the performance cost isn't worth catching the accidental invalid
value.
Hi,
On Monday, 2 March 2026 at 19:54, Christian Schneider <
cschneid@cschneid.com> wrote:Am 02.03.2026 um 20:12 schrieb Tim Düsterhus tim@bastelstu.be:
Playing my favourite broken record:
Can we please state that additions of Exceptions should (in most
cases) go through anE_WARNINGphase to allow a time window to fix code
before changing the behaviour?“Not passing invalid values” is perfectly backwards compatible.
Folks can just fix their code before upgrading their production deployment
to the new PHP version, e.g. by trying out the new PHP version in a staging
system or running CI for both the old and new PHP version.
- Not everybody has access to a staging system, e.g. people running
stuff on hosting services.- As a hoster I'd rather have a phase where my customers get warnings
instead of errors, creates less emergency support load.In practice an
E_WARNINGis no less breaking than going straight to
an Error, because:
- The common frameworks include error handlers that just convert
any warning and notice to an Exception.So in that sense there is also no advantage to NOT having a warning
phase for those people.
But people treatingE_WARNINGdifferent from Exceptions (which is
probably the exact people whose code breaks with an immediate Exception) do
have a time window to fix things.
- The code is already broken, because it relies on unspecified
behavior. The error would just making the user aware that the code is very
likely not doing what it appears to be doing based on the input values
passed to a function.It can easily do something valid and ignore the extra bits (pun kind
of intended), see
mkdir("foo", 070777);
which passes extra bits with are ignored but the application was
behaving in a completely deterministic and valid way.Going through an
E_WARNINGwould add maintainer busywork and
complicate the php-src codebase for no real gain.We've been over this before:
If people really feel that the additional burden to change the code
twice then I'd be happy to volunteer providing a small helper
function/macro to generate anE_WARNINGand either (the more aggressive
approach) switch to an exception once a certain PHP version is reached or
(probably the more flexible way) issue a compile time warning/error
informing the maintainer to switch the warning to an Exception.
The most simplistic version of this is a FIXME comment annotated with
a version number. Easy to grep, easy to trigger automatic alerts about once
the specified version is reached, but it can also be something more
sophisticated..
One way or the other could also be integrated into the CI/CD system.Our main disagreement is about the "no real gain" part as it IMHO
targets the long tail of PHP code / developers out there not using
full-fledged frameworks and dev environments or running legacy software on
hosting services.I am very much in favor of making things easy for the code developers
but I am of the strong believe that it can be done in a good way for
developers.I don't see how going through an
E_WARNINGphase is helpful, rather I
see it as detrimental.
Foremost, what is the behaviour of introducing a warning?
Do we exit early and return false?
Or do we just warn and continue to use a possible default or nonsensical
value?
AFAIK every time a warning got introduced it followed the first
approach, so this doesn't seem to address the concern of giving developers
more time.
However, if we do continue using the prior behaviour then we haven't
solved the concern in the slightest.
As it may be a warning for one PHP version and in the next PHP version
the extension supports a new flag which removes the warning for that value,
leading back to a silent BC break if the warning wasn't addressed.Another technical aspect is that warnings allows userland code to run
and change the state of the VM and extension in unexpected way (we have
countless fuzzying reports about this) an issue that does not exist with
Exceptions.Then comes the topic about how long should it be a warning? Until the
next major? A single release cycle? I don't want warning promotion to
become the same exhausting discussion that deprecation duration already is.I have no idea how you handle hosting, but when I used shared hosting in
the past I would never have anyone tell me that my code was producing
warnings or notices.
And even the one website I manage for someone which is on OVH shared
hosting I can still select a PHP version (heck even downgrading to 5.4 for
some reason).
So I'm struggling to see how for the average end user this is impacting
them?
And if you do just bump the PHP version for them, I'm not sure what's
the difference between having an Error immediately or producing warnings
for X years before throwing an Error and breakingBest regards,
Gina P. Banyard
I am in favour of exempting the validation errors from requiring RFCs,
and as Gina, I do not believe that warnings are useful. I don't like
that warnings even exist in the PHP language. I can see the case that
you don't want to break a running application by upgrading the PHP
version, but it can happen regardless. Minor PHP releases can contain
minor breaking changes and each time someone upgrades PHP, they should
run their test suite and verify that the application still works the
same as before. Whether we introduce a Warning or ValueError, it will
be caught during the upgrade process and fixed. It may even help avoid
nasty bugs if the application stops on invalid input; something which
could go unnoticed if it were only a warning.
Well the mentioned breaking changes must all go through RFC - that's our
policy. The reason is that breaking changes should get always a bit more
consideration. It doesn't mean that they cannot be done. If this RFC
passes, then the ValueError conversion can be done without RFC unless there
is an objection - it means any core developer can still require RFC if they
wish.
I am, however, concerned about one thing. If we don't require RFCs
there may be situations when a contentious validation is introduced.
For example, many validations can be implemented in such a way that
they don't cause additional performance loss, but let's say someone
decides that validating the value provides more benefit than the
performance cost. Without RFC, the community cannot share their
feedback, and one person's opinion wins. But if the function is used
with the correct values 99.99% of the time and it's used in the hot
code, the performance cost isn't worth catching the accidental invalid
value.
We could probably relay on some developers noticing such changes and
calling for RFC which can be done for any feature. But my worry is that
some of the cases that could be problematic just slip in and they might
cause problems for users later. So my preference is to require RFC for all
which should make sure that there is a good visibility for any such change.
Those changes are usually trivial so grouping them to a single RFC should
not be that much work.
Kind regards,
Jakub
[...]
We could probably relay on some developers noticing such changes and calling for RFC which can be done for any feature. But my worry is that some of the cases that could be problematic just slip in and they might cause problems for users later. So my preference is to require RFC for all which should make sure that there is a good visibility for any such change. Those changes are usually trivial so grouping them to a single RFC should not be that much work.
People have previously complained that the mass RFC deprecation has too many entries, and you want to propose something similar for ValueError?
And I'm against dragging out this sort of simple maintenance work onto an RFC stage which has frankly only gotten more tedious in the last few years.
Any RFC will delay the merging of those simple PRs by at least 4 weeks, and more likely multiple months.
This is IMHO an unacceptable way to do regular maintenance that can prevent real bugs ending up in production.
Best regards,
Gina P. Banyard
[...]
I am, however, concerned about one thing. If we don't require RFCs
there may be situations when a contentious validation is introduced.
For example, many validations can be implemented in such a way that
they don't cause additional performance loss, but let's say someone
decides that validating the value provides more benefit than the
performance cost. Without RFC, the community cannot share their
feedback, and one person's opinion wins. But if the function is used
with the correct values 99.99% of the time and it's used in the hot
code, the performance cost isn't worth catching the accidental invalid
value.
I don't think this concern is warranted in practice for at least 2 reasons:
- The majority of those functions are not going to be purely computational functions and are tied to some I/O operation
- These input checking guards should be wrapped in UNEXPECTED() hinting to the CPU that they should optimize for this branch not to be taken
Best regards,
Gina P. Banyard
Am 09.03.2026 um 14:36 schrieb Gina P. Banyard internals@gpb.moe:
I don't see how going through an
E_WARNINGphase is helpful, rather I see it as detrimental.
Foremost, what is the behaviour of introducing a warning?
Do we exit early and return false?
Or do we just warn and continue to use a possible default or nonsensical value?
in all the previous cases where we deprecated things we continued to leave the behaviour unchanged apart from issuing the warning.
AFAIK every time a warning got introduced it followed the first approach, so this doesn't seem to address the concern of giving developers more time.
Replace E_WARNING in your phrasing with E_DEPRECATED and your statement becomes obviously false.
If that's the differentiator for you then I'm happy to have an E_DEPRECATED phase before throwing a ValueError exception.
However, if we do continue using the prior behaviour then we haven't solved the concern in the slightest.
As it may be a warning for one PHP version and in the next PHP version the extension supports a new flag which removes the warning for that value, leading back to a silent BC break if the warning wasn't addressed.
Nothing can protect you from old code using a new flag by accident. Imagine someone skipping the version with the ValueError and going directly from 8.5 to the version with added flags. That's not the scope here.
Then comes the topic about how long should it be a warning? Until the next major? A single release cycle? I don't want warning promotion to become the same exhausting discussion that deprecation duration already is.
In my view it is exactly the same as deprecations and should be handled as such.
I'm on your side here that I don't want yet another process and that's why I'm advocating the IMHO tested and proven solution we are using for deprecations.
I have no idea how you handle hosting, but when I used shared hosting in the past I would never have anyone tell me that my code was producing warnings or notices.
And even the one website I manage for someone which is on OVH shared hosting I can still select a PHP version (heck even downgrading to 5.4 for some reason).
So I'm struggling to see how for the average end user this is impacting them?
I'm supporting applications running on hosters where they bump the minimal supported version quite often.
"Works for me" is hardly ever a strong argument...
Regards,
- Chris
Am 09.03.2026 um 14:36 schrieb Gina P. Banyard internals@gpb.moe:
I don't see how going through an
E_WARNINGphase is helpful, rather I see it as detrimental.
Foremost, what is the behaviour of introducing a warning?
Do we exit early and return false?
Or do we just warn and continue to use a possible default or nonsensical value?in all the previous cases where we deprecated things we continued to leave the behaviour unchanged apart from issuing the warning.
AFAIK every time a warning got introduced it followed the first approach, so this doesn't seem to address the concern of giving developers more time.
Replace
E_WARNINGin your phrasing withE_DEPRECATEDand your statement becomes obviously false.
If that's the differentiator for you then I'm happy to have anE_DEPRECATEDphase before throwing a ValueError exception.
These are not similar to deprecations. In these instances you have a silent bug that is being suppressed, and you should be aware of it loud and clear.
A deprecation is a mechanism to indicate that previously valid and bug free code is getting phased out.
These are fundamentally two different situations, thus I disagree that they should use a deprecation.
However, if we do continue using the prior behaviour then we haven't solved the concern in the slightest.
As it may be a warning for one PHP version and in the next PHP version the extension supports a new flag which removes the warning for that value, leading back to a silent BC break if the warning wasn't addressed.Nothing can protect you from old code using a new flag by accident. Imagine someone skipping the version with the ValueError and going directly from 8.5 to the version with added flags. That's not the scope here.
Then comes the topic about how long should it be a warning? Until the next major? A single release cycle? I don't want warning promotion to become the same exhausting discussion that deprecation duration already is.
In my view it is exactly the same as deprecations and should be handled as such.
I'm on your side here that I don't want yet another process and that's why I'm advocating the IMHO tested and proven solution we are using for deprecations.
As mentioned before I disagree that this is like a deprecation.
I have no idea how you handle hosting, but when I used shared hosting in the past I would never have anyone tell me that my code was producing warnings or notices.
And even the one website I manage for someone which is on OVH shared hosting I can still select a PHP version (heck even downgrading to 5.4 for some reason).
So I'm struggling to see how for the average end user this is impacting them?I'm supporting applications running on hosters where they bump the minimal supported version quite often.
"Works for me" is hardly ever a strong argument...
This then seems to be self-inflicted problems from these specific hosters.
Unless they take the QA responsibility to ensure the migration works, just blindly upgrading PHP's version seems frankly irresponsible.
Best regards,
Gina P. Banyard
Hi,
Hello internals,
I would like to propose a short policy RFC to formally exempt input type
and value validation from our BC Break policy.
The current wording of the policy already permits us to add validation of
inputs, but recently any such changes have been asked to submit an RFC
instead.
We believe that requiring an RFC for this type of change is detrimental
and adds unnecessary friction for routine maintenance activity and new
contributors.RFC: https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-policy
Message text is fine and it was my omission not to add it as we change it
already so thanks for that. It might be good to separate vote for this so
it definitely passes.
The ValueError is more problematic because as you can already see with
error_log() $message_type, it is not always that straight forward. I would
prefer we keep those decided on case by case basis which also gives a
better visibility.
Kind regards,
Jakub
Hello internals,
I would like to propose a short policy RFC to formally exempt input type and value validation from our BC Break policy.
The current wording of the policy already permits us to add validation of inputs, but recently any such changes have been asked to submit an RFC instead.
We believe that requiring an RFC for this type of change is detrimental and adds unnecessary friction for routine maintenance activity and new contributors.RFC: https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-policy
Best regards,
Gina P. Banyard
As the discussion has lasted over 2 weeks and was focused on, IMHO, irreconcilable differences in policy position; I intend to open the vote on Friday afternoon/evening European time.
Best regards,
Gina P. Banyard