On 07.05.2022 13:29, Mel Dafert wrote:
It is exactly user-defined functions that this RFC introduces breakage for.
The behaviour to throw on null in user-defined functions exists since PHP
7.0, and is being relied on. Changing these now would introduce behaviour
changes
that are harder to find than new type errors.
Using strict typing isn't an option either/would be just as much work as
auditing
the changes this would introduce.
It may be that user-defined functions should have accepted null to begin with in
your opinion, but that still makes it a breaking change now.
Indeed. I suggest to add a note to "Backward Incompatible Changes"
section of the RFC. This changes the contract, but does not throw new
errors in existing code.
Now my 2 cents, reading docs and RFCs (I'm not the internals developer):
The https://wiki.php.net/rfc/scalar_type_hints_v5 says that NULL was
excluded "in order to be consistent with our existing type declarations
for classes, callables and arrays".
So, to me it sounds like the main reason was that NULL can't be cast to
array/object/callable, not that it was expected to be treated as a new
type in the future, nor more strictness was intended.
At the time excluding NULL made sense as it was a new feature anyway,
and it didn't apply to internal functions, so it was fully sign-in
feature. Although I must say that "it should be possible for existing
userland libraries to add scalar type declarations without breaking
compatibility" wasn't really true, because of NULL.
You could call the proposed NULL-to-scalar coercion in weak-type checks
a new feature that makes
https://wiki.php.net/rfc/deprecate_null_to_scalar_internal_arg
obsolete/invalid, still, there are good reasons to do this. Imo, the BC
break is much less problematic than the one we're trying to solve here.
--
Aleksander Machniak
Kolab Groupware Developer [https://kolab.org]
Roundcube Webmail Developer [https://roundcube.net]
----------------------------------------------------
PGP: 19359DC1 # Blog: https://kolabian.wordpress.com
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
