Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127318
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.500.181.1.5\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Minor version compatibility
Date: Thu, 8 May 2025 11:28:28 +0200
References: <CAPTD5yFaQL58uJ3Focij9HKT-u-70fTDdzBWsqxpAru2YRZaqQ@mail.gmail.com>
 <YAFPTpeOTAw7NcYOqaFhRhEMMZTLzLtqVbMlPKWI-P2FwlxvoOfdKBQWyxO8Y_uXA903u1fwjP7reP45oyfvbyHy_W7gnP4HIrWxXP1TE7Y=@gpb.moe>
 <0433FF37-D938-4D3D-AC03-E5143218EFEA@cschneid.com>
 <RG1BNbOBzyHzqarQLUv0aO6cvo2ePyZ-Tt_bgRKR_9rSX_4glhTaHCx54Y9ykWXY_NzNgEUSu4yWv3hq0qIKZmCu15umaQmgjUPp62iz2A4=@gpb.moe>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <RG1BNbOBzyHzqarQLUv0aO6cvo2ePyZ-Tt_bgRKR_9rSX_4glhTaHCx54Y9ykWXY_NzNgEUSu4yWv3hq0qIKZmCu15umaQmgjUPp62iz2A4=@gpb.moe>
Message-ID: <94CC8457-6801-4C27-87F0-11CE93EAA135@cschneid.com>
From: cschneid@cschneid.com (Christian Schneider)

Am 08.05.2025 um 00:36 schrieb Gina P. Banyard <internals@gpb.moe>:
>> If this would have been done without warning phase then it would be a =
blocker for upgrading to PHP 8.4, now filtering this warning is enough =
while the packages are being updated.
>=20
> Comparing a core language change to be the same level as throwing a =
ValueError on invalid inputs of a bundled extension function is a bit of =
a straw man argument.
> The motivation for this policy change is _explicitly_ about input =
validation.

You are right in principle but from an application / installation =
maintainers point of view it is irrelevant if an application breaks =
because old code used a more relaxed language definition (as was the =
case with implicitly nullable parameters) or invalid arguments (a =
function might have ignored unknown flags).

> I am not saying break all the things, however, breaking clearly buggy =
code is something I consider a feature.

But now we have the problem of defining "clearly buggy code": If the =
output of some code was correct even though I gave some unknown flags to =
a function which were ignored I would call that "should be fixed" but =
not "clearly buggy".
That's why I'm advocating of treating it in two steps instead of one. =
That's all I'm saying.

Now there might be cases where you feel like the parameter value is =
clearly wrong but instead of having to decide that for each and every =
instance (and people might disagree) I find it easier to err on the =
delayed-BC-break side.

> Letting users ship buggy code in production is not something that I =
find at all reasonable.
> And I am looking forward to your suggestion on how to simply implement =
this for every single unique validation error that we encounter.

Either do something like
	zend_warn_or_throw_exception(E_WARNING, zend_ce_value_error, =
80500, "Invalid argument ...", ...);
which automatically either outputs a warning or throw an exception =
depending on the PHP version or something like
	zend_error(E_WARNING, "Invalid argument ...", '...);	/* FIXME =
PHP_VERSION_ID 80500 */
which can be grepped / warned about in CI/CD whenever the PHP version is =
changed and changed to a zend_throw_exception(...) at that point.

This assumes that it would be possible to define a clear point where the =
switch from E_WARNING to ValueError should happen but it seems doable to =
me without putting a lot of burden on core developers.

Regards,
- Chris