On Mon, 24 Jan 2022 at 23:47, Mark Randall <marand...@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
