Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126866
Date: Thu, 20 Mar 2025 16:00:06 +0000
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Consensus on argument validation for built-in functions
Message-ID: <M9xldW5CjeyMjQIM_miFqNS9uTwWcSW0T4XzbVa1NyENRazh35tQfs-PVy-WKMBQQQ3E-6MJgH_ISgjo9XuXc1TGm7lq6QK1nh4z_-ItvpY=@gpb.moe>
In-Reply-To: <95d08053-7500-4cc3-b84b-cb7cc837c065@rwec.co.uk>
References: <CAPTD5yHhpcJJDNWMCpQSrkGyY5+YtgKUy1OKYv5t03KyzoAXbA@mail.gmail.com> <XOTiGCaoOV5bvCQP2nMZW7AzIoOdH5la7sgmJ8KK51Z6n9zJLiAM7cYTiUhH5zsrrMbMUZe257bmPe8SgcNgN2IqNzPUty68egntFngnsXU=@gpb.moe> <C3E24D9F-3D72-401F-81A9-CAA245308703@cschneid.com> <041d1a8c-dd43-4592-b997-ad4d2f91aeac@app.fastmail.com> <C0CFBD16-810E-4D4D-B818-4CB0E89DE25A@rwec.co.uk> <CG7fDapdXYGFwt0ryH-8s-dXCBrVw7gSIpgYYvKRDg_mlTjjuyro5uy1V5JLKzf21if2GLbjNv5zJ6M-7Szkj5URUdyXQWIZ0_b2wNUKbVE=@gpb.moe> <95d08053-7500-4cc3-b84b-cb7cc837c065@rwec.co.uk>
Feedback-ID: 96993444:user:proton
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: internals@gpb.moe ("Gina P. Banyard")

On Tuesday, 11 March 2025 at 21:17, Rowan Tommins [IMSoP] <imsop.php@rwec.c=
o.uk> wrote:
> On 11/03/2025 11:54, Gina P. Banyard wrote:
>=20
> > It also means that we need to do multiple passes, on the same code path=
, resulting in somewhat of a code churn and possibly not using a common abs=
traction.
> > Considering that we didn't even have the time to properly remove some d=
eprecations from PHP 7 with the PHP 8.0.0 release, nor convert all relevant=
 E_WARNINGs to Value/Type errors, I expect that we would be missing some of=
 them again when PHP 9 comes around.
>
> I wonder if in some cases, we could automate this within the source code
> - e.g. with a macro like WARNING_OR_ERROR(message,
> first_version_for_error) which checks a compile-time constant for the
> current version. I realise that still requires code cleanup later, but
> it means we can't miss our chance when the appropriate version does come
> around.

I don't think this is an improvement for the maintenance side.

> > and this is ignoring the fact that PHP does not follow semver
>=20
> This is true, but only in the sense that something under the MIT license
> isn't under the BSD license. Officially, PHP's release policy is
> extremely similar to SemVer.
>
> [...]
>=20
> Now, what exactly constitutes "backward compatibility" and "userland API
> compatibility" can be debated, but there is currently no agreed policy
> allowing "small compatibility breaks".
>=20
> The fact that everyone acts as though there is such a policy, probably
> means a rewrite of that document is overdue. A policy that nobody
> follows is no use to either contributors or users.

Yes, rewriting this policy would be a good idea.
There have been BC breaks in every minor release going all the way back to =
PHP 4.

> Maybe we could work on some criteria that could be applied (and
> publicised to users) about what is and isn't allowed in minor versions.
>
> [...]
>
> We'd probably still want some kind of deprecation policy - some changes
> should be deprecated for X releases before removal/change. Which brings
> us back to some kind of criteria for which changes need that, so doesn't
> really solve the problem.

Indeed, none of this really solves the problem.
I think it is *fair* that the Core language has more stringent requirements=
 on BC than anything else.
The standard library being second in line for this sort of considerations.
But every other bundled extension should be allowed to have way more leeway=
 in what said extension maintainer wants to do.

Making a distinction between Type and Value errors is meaningless to me,
if PHP had a stronger type system, e.g. dependent types,
then, a lot of things we currently consider ValueErrors would be TypeErrors=
.

If we were also designing some of these functions from scratch today, a lot=
 of parameters wouldn't integers, but enums.
The only exception to this are bitmask parameters, as we don't have Enum Se=
ts (or Intersection Types as values) which would replace those.

And again, ValueErrors are only ever added when it *easy* to check if the c=
ondition is satisfied, and it very clearly points to a programming error.

I still find it baffling that telling someone that the code they wrote, eve=
n if it is decades old, is incorrect is somehow bad.
Because the alternative is letting users have bugs in their software that t=
hey can ignore.


Best regards,

Gina P. Banyard