Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127095
Precedence: bulk
MIME-Version: 1.0
References: <CAPTD5yHhpcJJDNWMCpQSrkGyY5+YtgKUy1OKYv5t03KyzoAXbA@mail.gmail.com>
In-Reply-To: <CAPTD5yHhpcJJDNWMCpQSrkGyY5+YtgKUy1OKYv5t03KyzoAXbA@mail.gmail.com>
Date: Fri, 11 Apr 2025 12:33:50 +0200
Message-ID: <CAEKnhAFdwYV1D+Dt+LzwVdzPAaa904ORnMBe0piN0G86g7v-iA@mail.gmail.com>
Subject: Re: [PHP-DEV] Consensus on argument validation for built-in functions
To: Jorg Sowa <jorg.sowa@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a8842306327e3d5f"
From: bukka@php.net (Jakub Zelenka)

--000000000000a8842306327e3d5f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Tue, Mar 11, 2025 at 12:09=E2=80=AFAM Jorg Sowa <jorg.sowa@gmail.com> wr=
ote:

> Hello everyone,
>
> I=E2=80=99d like to align on the approach to validating arguments for bui=
lt-in
> functions (usually for flag inputs). Some ongoing discussions in PRs:
> - https://github.com/php/php-src/pull/15647
> - https://github.com/php/php-src/pull/15883
> - https://github.com/php/php-src/pull/17859
>
> In some cases, changes introduced ValueError immediately in the next
> version, without a deprecation phase. To ensure a consistent approach, I
> propose the following:
>
> 1. Introduce a deprecation notice in the next minor version.
> 2. Raise a ValueError in the following minor version.
> If needed, I can create RFC, but as described by a few people in the
> discussions, we can avoid it having the consensus. What do you think?
>
>
I would personally prefer also go through the deprecation first to be on
the safe side.

This thread clearly shows that there is no consensus so I think the only
way forward would be to create a policy RFC to make decision about this
approach. Until then no PR introducing exception, deprecation or just plain
warning for this sort of things should be merged.

Kind regards

Jakub

--000000000000a8842306327e3d5f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><br><div class=3D"gmail_quote gmail_quote_co=
ntainer"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Mar 11, 2025 at 12:0=
9=E2=80=AFAM Jorg Sowa &lt;<a href=3D"mailto:jorg.sowa@gmail.com">jorg.sowa=
@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div>Hello everyone,<br></div><div><br></div><d=
iv>I=E2=80=99d like to align on the approach to validating arguments for bu=
ilt-in functions (usually for flag inputs). Some ongoing discussions in PRs=
:<br>- <a href=3D"https://github.com/php/php-src/pull/15647" target=3D"_bla=
nk">https://github.com/php/php-src/pull/15647</a><br>- <a href=3D"https://g=
ithub.com/php/php-src/pull/15883" target=3D"_blank">https://github.com/php/=
php-src/pull/15883</a><br>- <a href=3D"https://github.com/php/php-src/pull/=
17859" target=3D"_blank">https://github.com/php/php-src/pull/17859</a></div=
><div><p>In some cases, changes introduced <code>ValueError</code> immediat=
ely in the next version, without a deprecation phase. To ensure a consisten=
t approach, I propose the following:<br><br>1. Introduce a deprecation noti=
ce in the next minor version.<br>2. Raise a <code>ValueError</code> in the =
following minor version.</p>If needed, I can create RFC, but as described b=
y a few people in the discussions, we can avoid it having the consensus. Wh=
at do you think?</div><div><br></div></div></blockquote><div><br></div><div=
>I would personally prefer also go through the deprecation first to be on t=
he safe side.</div><div><br></div><div>This thread clearly shows that there=
 is no consensus so I think the only way forward would be to create a polic=
y RFC to make decision about this approach. Until then no PR introducing ex=
ception, deprecation or just plain warning for this sort of things should b=
e merged.</div><div><br></div><div>Kind regards</div><div><br></div><div>Ja=
kub</div></div></div>

--000000000000a8842306327e3d5f--