Am 08.05.2025 um 00:36 schrieb Gina P. Banyard <intern...@gpb.moe>:
>> If this would have been done without warning phase then it would be a
>> blocker for upgrading to PHP 8.4, now filtering this warning is enough while
>> the packages are being updated.
>
> Comparing a core language change to be the same level as throwing a
> ValueError on invalid inputs of a bundled extension function is a bit of a
> straw man argument.
> The motivation for this policy change is _explicitly_ about input validation.
You are right in principle but from an application / installation maintainers
point of view it is irrelevant if an application breaks because old code used a
more relaxed language definition (as was the case with implicitly nullable
parameters) or invalid arguments (a function might have ignored unknown flags).
> I am not saying break all the things, however, breaking clearly buggy code is
> something I consider a feature.
But now we have the problem of defining "clearly buggy code": If the output of
some code was correct even though I gave some unknown flags to a function which
were ignored I would call that "should be fixed" but not "clearly buggy".
That's why I'm advocating of treating it in two steps instead of one. That's
all I'm saying.
Now there might be cases where you feel like the parameter value is clearly
wrong but instead of having to decide that for each and every instance (and
people might disagree) I find it easier to err on the delayed-BC-break side.
> Letting users ship buggy code in production is not something that I find at
> all reasonable.
> And I am looking forward to your suggestion on how to simply implement this
> for every single unique validation error that we encounter.
Either do something like
zend_warn_or_throw_exception(E_WARNING, zend_ce_value_error, 80500,
"Invalid argument ...", ...);
which automatically either outputs a warning or throw an exception depending on
the PHP version or something like
zend_error(E_WARNING, "Invalid argument ...", '...); /* FIXME
PHP_VERSION_ID 80500 */
which can be grepped / warned about in CI/CD whenever the PHP version is
changed and changed to a zend_throw_exception(...) at that point.
This assumes that it would be possible to define a clear point where the switch
from E_WARNING to ValueError should happen but it seems doable to me without
putting a lot of burden on core developers.
Regards,
- Chris
