Hi
On 3/2/26 14:49, Christian Schneider wrote:
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?
“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:
1.
The common frameworks include error handlers that just convert any
warning and notice to an Exception.
2.
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
