Re: Long-Term Planning for PHP 9.0 Error Promotion

From: Date: Wed, 26 Jan 2022 16:42:41 +0000
Subject: Re: Long-Term Planning for PHP 9.0 Error Promotion
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-116931@lists.php.net to get a copy of this message
On Mon, 24 Jan 2022 at 23:47, Mark Randall <marandall@php.net> wrote: > Let's open a discussion as to what we might want to do in the future, > and depending on how things shake out, we can decide what route to take > with regards to bringing RFCs to vote. > While I did begin an RFC to allow *some* functions to be more tolerant of NULL, especially for those scripts not using strict_types: https://wiki.php.net/rfc/allow_null Or in other words, to "relax certain type requirements on a case by case basis", ref the original discussion: https://externals.io/message/112327 The only feedback I've received is that it's a "terrible idea" (no details), "it's a bit late" (deprecations have already been issued, full steam ahead?), and the typical objections/negativity (-4 points on externals.io, not quite a record, but getting there). The view seems to be that every single PHP developer must use *strict* static analysis (e.g. Psalm at levels 1 to 3, with no baseline), and tools like Rector or PHPCompatibility (neither of which handle this problem; where I'll note that it will be hard to do, as it involves tracking every single variable from source to sink). While I'm not a C programmer, I was just thinking of replacing some uses of Z_PARAM_STR with something similar to Z_PARAM_STR_OR_NULL, maybe calling it Z_PARAM_STR_ALLOW_NULL, where it would return an empty string for NULL with scripts not using strict_types... but I got the impression this would be unacceptable. So I assume, with this PHP 9.0 discussion, we should just get on with this ideological purity, move on from deprecation, and raise a Fatal Error for everyone committing heinous crimes such as: echo htmlspecialchars($name); Where $name might contain NULL, due to using something like ($_GET['name'] ?? NULL), as used by some minor frameworks like Laravel, Symfony, CakePHP, CodeIgniter, etc - a pattern used to denote a value not being provided by the user. As an aside, I love how the RFC template includes this example quote from Rasmus: > PHP is and should remain: > 1) a pragmatic web-focused language > 2) a loosely typed language > 3) a language which caters to the skill-levels and platforms of a wide range of users And, yes, I am venting, but who cares, I'm not going to change anyones mind. Craig

« previous php.internals (#116931) next »