On Thu, May 26, 2022 at 7:21 AM Craig Francis <cr...@craigfrancis.co.uk> wrote:
> That said, I would still like to know about the benefits of rejecting NULL > for `htmlspecialchars()`, in the context of that Laravel Blade patch; > because, if it is beneficial (vs the BC break), they should revert that > patch... shouldn't they? > No, they should not. Laravel made an explicit choice to handle null values in its escaping function for its templating framework. That is their choice to make. They should not be forced to implicitly handle null values because the language decides to add implicit type coercion to user defined functions (because consistency seems to be so important to some), and they should not be forced to reject null values because underlying language functions reject them as well. Every implicit type coercion is a bug in hiding IMO. If something doesn’t explicitly support null, you shouldn’t have been passing null to it in the first place. Relying on magic language behaviors to prevent type errors is not a long term sustainable code pattern. If a function, by explicit design, can safely work with null values then that parameter should be properly declared nullable. If a function, by explicit design, does not support null values then a type error is a hugely acceptable response. Yes, that means that there is a lot of work involved for folks between now and the release of PHP 9.0 to either refactor code to avoid type errors or to get the language to expand the supported types in appropriate functions, but IMO that effort from all parties is worth it in the long run to ensure language consistency (I really don’t think userland PHP and internal/extension PHP should have vastly different behaviors, and type coercion support based on where a function is designed is one of those holes that needs filled) and to ensure all APIs explicitly declare what types of data they support. -- - Michael Please pardon any errors, this message was sent from my iPhone.
