On Tue, Mar 11, 2025, at 10:07, Christian Schneider wrote: > Am 11.03.2025 um 07:32 schrieb Gina P. Banyard <intern...@gpb.moe>: > > On Monday, 10 March 2025 at 23:07, Jorg Sowa <jorg.s...@gmail.com> 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
