On 01-03-2022 19:10, Craig Francis wrote:
I'm pretty confident the best solution is to keep all parameter types the
same (I could argue that some parameters could do with a "cannot be empty"
exception, to reject NULL and an Empty String, but that would be a
different RFC)... and anyone using `strict_types` will still have a Type
Error when they pass a value of the wrong type to these parameters... the
*only* change is for those not using `strict_types`, for NULL to still be
coerced to a string/int/float/bool, as it always has been for internal
functions... and I think this can be done to user functions as well, as
developers not using strict_types won't have cared about this before.
Craig
Hi Craig,
So, to get this crystal clear, this is my understanding of what you are
proposing for passing null to a non-nullable function parameter
(hopefully my ASCII art will come through ok):
which | strict_types | PHP 8.0 | PHP 8.1 | PHP 9
----------|---------------|------------|------------|----------
user | 1 | TypeError | TypeError | TypeError
internal | 1 | TypeError | TypeError | TypeError
user | 0 | TypeError | TypeError | coerced
internal | 0 | coerced | Deprecated | coerced
Is this correct?
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
