Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127252
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: Wed, 30 Apr 2025 14:12:46 +0200
References: <CAPTD5yFaQL58uJ3Focij9HKT-u-70fTDdzBWsqxpAru2YRZaqQ@mail.gmail.com>
 <YAFPTpeOTAw7NcYOqaFhRhEMMZTLzLtqVbMlPKWI-P2FwlxvoOfdKBQWyxO8Y_uXA903u1fwjP7reP45oyfvbyHy_W7gnP4HIrWxXP1TE7Y=@gpb.moe>
To: PHP internals <internals@lists.php.net>
In-Reply-To: <YAFPTpeOTAw7NcYOqaFhRhEMMZTLzLtqVbMlPKWI-P2FwlxvoOfdKBQWyxO8Y_uXA903u1fwjP7reP45oyfvbyHy_W7gnP4HIrWxXP1TE7Y=@gpb.moe>
Message-ID: <0433FF37-D938-4D3D-AC03-E5143218EFEA@cschneid.com>
From: cschneid@cschneid.com (Christian Schneider)

Am 27.04.2025 um 20:22 schrieb Gina P. Banyard <internals@gpb.moe>:
> I fundamentally reject the concept of this RFC to restrict our ability =
to do input validation.

I am sorry but I fail to see how the RFC restrict the ability to do =
input validation.

> Emitting an E_DEPRECATED for invalid inputs remains utter nonsense.

I agree that it should most probably be an E_WARNING, not an =
E_DEPRECATED. Which is a voting option in the RFC.

> I will repeat this once again, but error-ing on *invalid* inputs =
entered by the developer is an *advantage*.
> I cannot comprehend the motivation to let users ship buggy code into =
production, that might end up hard to debug.
> We throw Errors on non-existent constants, functions, classes, etc. =
for a reason.

I am *not* against error-ing on invalid input, and I don't think anyone =
else is.
It is all about the migration path for existing software and having =
guidelines for such changes.

Using intermediate warnings before going to an Exception allows updating =
an installation step-by-step instead of all at once. Which is important =
both for projects using a lot of composer packages as well as =
installations where PHP and applications are maintained by different =
people (e.g. hosting companies).

Case-studies regarding implicitly nullable parameters and the warning =
phase:
- https://github.com/hybridauth/hybridauth/releases with fixes for PHP =
8.4 was released only last week
- https://github.com/grpc/grpc-php still has not released fixes for PHP =
8.4

Sure, this is from one minor version to the next and not about invalid =
argument values and it uses E_DEPRECATED instead of E_WARNING but my =
main points stays the same:
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.

And I am of the very strong opinion that the benefits of reducing =
friction for upgrading to the current PHP version outweighs the costs. =
Forgetting to change the warning to an Exception can be simply prevented =
by e.g. a helper function or even a greppable code comment.

> As such, if this policy does get accepted, I will start to severely =
reduce my contributions to the project.
> As it would be a clear sign to me that what people want from the =
project is something that I find completely nonsensical and thus I =
should direct my energy and time to something more inline with my own =
design beliefs.

I find it very unfortunate that you are feeling the need to pressure the =
community in this way as I can assure you that we all want the project =
to improve even it is sometimes in different ways.

Regards,
- Chris