Re: [RFC] Exempt input type and value validation from BC Break policy

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