Am 27.04.2025 um 20:22 schrieb Gina P. Banyard <intern...@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
