Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126713
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Tue, 11 Mar 2025 11:20:52 +0100
To: internals@lists.php.net
Message-ID: <041d1a8c-dd43-4592-b997-ad4d2f91aeac@app.fastmail.com>
In-Reply-To: <C3E24D9F-3D72-401F-81A9-CAA245308703@cschneid.com>
References: 
 <CAPTD5yHhpcJJDNWMCpQSrkGyY5+YtgKUy1OKYv5t03KyzoAXbA@mail.gmail.com>
 <XOTiGCaoOV5bvCQP2nMZW7AzIoOdH5la7sgmJ8KK51Z6n9zJLiAM7cYTiUhH5zsrrMbMUZe257bmPe8SgcNgN2IqNzPUty68egntFngnsXU=@gpb.moe>
 <C3E24D9F-3D72-401F-81A9-CAA245308703@cschneid.com>
Subject: Re: [PHP-DEV] Consensus on argument validation for built-in functions
Content-Type: multipart/alternative;
 boundary=e13ec0499d3241998b31de2aacdb3f78
From: rob@bottled.codes ("Rob Landers")

--e13ec0499d3241998b31de2aacdb3f78
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 11, 2025, at 10:07, Christian Schneider wrote:
> Am 11.03.2025 um 07:32 schrieb Gina P. Banyard <internals@gpb.moe>:
> > On Monday, 10 March 2025 at 23:07, Jorg Sowa <jorg.sowa@gmail.com> w=
rote:
> >> I=E2=80=99d like to align on the approach to validating arguments f=
or built-in functions (usually for flag inputs). Some ongoing discussion=
s in PRs:
> >> - https://github.com/php/php-src/pull/15647
> >=20
> > 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.
>=20
> I'll sound a bit like a broken record :-)
>=20
> The very first example shows why we should have an E_WARNING phase to =
smoothen BC changes:
> Code like
> $a =3D array_filter(["a", "", "b"], strlen(...), 666);
> which currently ignores the bogus value and allows the code to continu=
e would suddenly stop with en Exception.
>=20
> Fixing the code is trivial and a warning helps identify those code loc=
ations 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 eve=
n though we've upgraded to the new version already.
>=20
> Conclusion:
> Yes, I'd very much like the 1) warning 2) ValueError approach from the=
 original mail to be the default.
>=20
> Regards,
> - Chris
>=20

Well, when you make it an exception, it usually gets upgraded/fixed fast=
er :)=20

=E2=80=94 Rob
--e13ec0499d3241998b31de2aacdb3f78
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Tue, Mar 11,=
 2025, at 10:07, Christian Schneider wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>Am 11.03.2025 um 07:32 schrieb Gina P. =
Banyard &lt;<a href=3D"mailto:internals@gpb.moe">internals@gpb.moe</a>&g=
t;:<br></div><div>&gt; On Monday, 10 March 2025 at 23:07, Jorg Sowa &lt;=
<a href=3D"mailto:jorg.sowa@gmail.com">jorg.sowa@gmail.com</a>&gt; wrote=
:<br></div><div>&gt;&gt; I=E2=80=99d like to align on the approach to va=
lidating arguments for built-in functions (usually for flag inputs). Som=
e ongoing discussions in PRs:<br></div><div>&gt;&gt; -&nbsp;<a href=3D"h=
ttps://github.com/php/php-src/pull/15647">https://github.com/php/php-src=
/pull/15647</a><br></div><div>&gt;&nbsp;<br></div><div>&gt; My opinion o=
n this topic is well known, validation errors should go straight to a Va=
lueError.<br></div><div>&gt; And if not a ValueError then it should be a=
n E_WARNING.<br></div><div>&gt; Raising a deprecation is frankly non-sen=
sical.<br></div><div><br></div><div>I'll sound a bit like a broken recor=
d :-)<br></div><div><br></div><div>The very first example shows why we s=
hould have an E_WARNING phase to smoothen BC changes:<br></div><div>Code=
 like<br></div><div>$a =3D array_filter(["a", "", "b"], strlen(...), 666=
);<br></div><div>which currently ignores the bogus value and allows the =
code to continue would suddenly stop with en Exception.<br></div><div><b=
r></div><div>Fixing the code is trivial and a warning helps identify tho=
se code locations but decoupling the moment of upgrading PHP from having=
 to fix all code is IMHO still valuable. Especially when using third-par=
ty packages which might have a delay in fixing it.<br></div><div>I'm sti=
ll waiting on some packages to fix new warnings for PHP 8.4 even though =
we've upgraded to the new version already.<br></div><div><br></div><div>=
Conclusion:<br></div><div>Yes, I'd very much like the 1) warning 2) Valu=
eError approach from the original mail to be the default.<br></div><div>=
<br></div><div>Regards,<br></div><div>- Chris<br></div><div><br></div></=
blockquote><div><br></div><div>Well, when you make it an exception, it u=
sually gets upgraded/fixed faster :)&nbsp;</div><div><br></div><div id=3D=
"sig121229152">=E2=80=94 Rob<br></div></body></html>
--e13ec0499d3241998b31de2aacdb3f78--