Re: Consensus on argument validation for built-in functions
On Tue, Mar 11, 2025, at 10:07, Christian Schneider wrote:
> Am 11.03.2025 um 07:32 schrieb Gina P. Banyard <[email protected]>:
> > On Monday, 10 March 2025 at 23:07, Jorg Sowa <[email protected]> wrote:
> >> I’d like to align on the approach to validating arguments for built-in functions
> >> (usually for flag inputs). Some ongoing discussions in PRs:
> >> - https://github.com/php/php-src/pull/15647
> >
> > My opinion on this topic is well known, validation errors should go straight to a
> > ValueError.
> > And if not a ValueError then it should be an E_WARNING.
> > Raising a deprecation is frankly non-sensical.
>
> I'll sound a bit like a broken record :-)
>
> The very first example shows why we should have an E_WARNING phase to smoothen BC changes:
> Code like
> $a = array_filter(["a", "", "b"], strlen(...), 666);
> which currently ignores the bogus value and allows the code to continue would suddenly stop
> with en Exception.
>
> Fixing the code is trivial and a warning helps identify those code locations but decoupling the
> moment of upgrading PHP from having to fix all code is IMHO still valuable. Especially when using
> third-party packages which might have a delay in fixing it.
> I'm still waiting on some packages to fix new warnings for PHP 8.4 even though we've
> upgraded to the new version already.
>
> Conclusion:
> Yes, I'd very much like the 1) warning 2) ValueError approach from the original mail to be
> the default.
>
> Regards,
> - Chris
>
Well, when you make it an exception, it usually gets upgraded/fixed faster :)
— Rob
Thread (16 messages)