On Tuesday, 11 March 2025 at 11:12, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> > On 11 March 2025 10:20:52 GMT, Rob Landers rob@bottled.codes wrote: > > > Well, when you make it an exception, it usually gets upgraded/fixed faster > > :) > > > Not necessarily. When people see long lists of breaking changes in a release, > they may just put off upgrading / marking the library compatible. > > I think we should be very wary of how far we bend the difference between > "minor" and "major" releases. > > For these changes, I'd like to hear the argument against starting with a > Warning. Is there any significant burden to waiting until 9.0 for these to > become errors? > > Rowan Tommins > [IMSoP] Consistency. Just staring at ext/pcntl and the git blame you can see that some functions validate the signal number (or flags) since PHP 8.0, others do not or only recently (commit from November 2023). The reason being that the code was inconsistent in when it would actually warn in the first place. The other one is data loss concerns, many functions that forward strings to C APIs don't check that they do not contain nul bytes, and thus the C API receives a truncated string. Or C API require a C int, which is 32bit compared to a PHP int which can be 64 bit, so truncation may happen for large negative/positive values. It also means that we need to do *multiple* passes, on the same code path, resulting in somewhat of a code churn and possibly not using a common abstraction. Considering that we didn't even have the time to properly remove some deprecations from PHP 7 with the PHP 8.0.0 release, nor convert all relevant E_WARNINGs to Value/Type errors, I expect that we would be missing some of them again when PHP 9 comes around. (and this is ignoring the fact that PHP does not follow semver, and I'm starting to really believe that any "semver-like" versioning system just does not work for a PL, especially not one like PHP which has an insanely vast API surface.) Moreover, changing a silent error condition to throwing a ValueError on a programming error that really never should be happening in the first place is not a disruptive BC break IMHO. And I will be repeating what I've been saying again and again, none of these issues would exist if bundled extensions did not exist. The fact that these extensions are tied to the "core PHP language" release cadence is.... incredibly annoying for everyone, from maintainers to users. Taking the example of ext/pcntl again, if it were a standalone extension, having it follow semver is a way more reasonable proposition. Because we could just release 2 versions the same day, a x.y+1.0 introducing a warning, and a x+1.0.0 which would convert them into proper errors. Meaning as a user, you could be running whatever PHP version and have the stricter behaviour, or upgrade PHP while still holding the ext/pcntl version behind while you deal with the issues. (Bonus points, the issue where PIE is currently unable to install bundled extension [1] would be solved with unbundling too.) Best regards, Gina P. Banyard [1] https://github.com/php/pie/issues/133
