On Mon, 28 Feb 2022 at 17:42, Larry Garfield <la...@garfieldtech.com> wrote:
> Bringing internal functions into line with user-space was the correct > move. There may be internals functions that make sense to be nullable on > their own right, on a case by case basis. We can evaluate that case by > case. > Thanks Larry, I agree about bringing them into line, but I think our understanding of NULL may be different... these are PHP scripts which have used NULL as a distinct value for, well, forever? and many developers expect it to be coerced like the other values. And while some developers use strict_types=1 (like myself) because we like the type to match up without values being coerced (I should be the one that manually chooses to convert)... I don't think I should force that strict coding style onto everyone, because there is nothing technically wrong with passing NULL into functions like urlencode(), it just implies, iff you use strict_types=1, that something may have gone wrong earlier. As an aside, I often note that many developers who talk about how strict their code is... obv not you, but many still use 'unsafe-inline' JavaScript on their websites (mixing content), and don't use Trusted Types to disable unsafe JS APIs, which I consider a much bigger security concern :-) And after all of this, no-one has come up with a way to find or address this problem, e.g. <?php $nullable = ($_GET['a'] ?? NULL); echo htmlentities($nullable); ?> ./vendor/bin/psalm --init ./public/ 4 ./vendor/bin/psalm No errors found! ./vendor/bin/phpstan analyse -l 9 ./public/ [OK] No errors ./vendor/bin/phpcs -p public/ --standard=PHPCompatibility . 1 / 1 (100%) ./vendor/bin/rector process ./public/ [OK] Rector is done! Craig
