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
