On 28.02.2022 at 23:11, Christian Schneider wrote: > Am 28.02.2022 um 22:05 schrieb Christoph M. Becker <cmbecke...@gmx.de>: > >> On 28.02.2022 at 21:51, Craig Francis wrote: >> >>> 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); >>> ?> >> >> <?php >> function my_htmlentities(string|null $value) { >> return htmlentities($value ?? ""); >> } >> >> $nullable = ($_GET['a'] ?? NULL); >> echo my_htmlentities($nullable); >> ?> >> >> The BC break doesn't appear to be that serious after all. > > I'm not sure I get your point here: If you provide a user-land implementation > of the previous behavior under a different name then the BC break cannot be > serious?
I said, the BC break doesn't appear to be *that* serious. To elaborate: in my opinion, it is a good thing if internal functions and userland functions behave the same regarding parameter types. As such I'm fine with bringing internal functions inline with userland functions. A somewhat reasonable alternative would be to bring userland functions inline with internal functions (prior to PHP 8.1.0). However, picking *some* functions and make *some* of their parameters nullable does not look reasonable to me; that is just a hack to not break *some* code, but still would not work for a lot of other code (e.g. code using PECL extensions, which may not be changed in this regard), and would make it harder to remember which parameters of which functions are nullable now (and which have special meaning for null, and which do simply treat null as an empty string). Since it has been brought up multiple times that it is hard to find all occurrences which would have to be adapted, I suggested a somewhat viable solution for userland code (namely to define userland functions which establish the old behavior; and of course, you'd need some tooling to replace the original function calls). So everybody *could* use this technique for those functions where it's relevant to the code base at hand. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php