On 22-1-2024 10:50, Gina P. Banyard wrote:
Hello internals,
Máté Kocsis and myself would like to propose deprecating implicitly nullable
parameter types.
The RFC is available on the wiki at the following address:
https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
Best regards,
Gina P. Banyard
For what it's worth, I support this deprecation - one less "exception to
the rule" to have to take into account and remember.
As for the RFC:
* While I don't think the impact will be that large and the fix is
straight-forward, I believe it would still be good to include an impact
analysis
(top 2000 Packagist packages check) in the RFC to confirm this.
* The RFC currently only talks about deprecating the syntax in PHP 8.4
and makes no mention of removing support for the syntax altogether
in the future. Would it be an idea to include a proposal for
removal of the syntax in the RFC ?
* The RFC does not mention the impact of the function signature change
on inheritance. I think it would be good to clarify that there is none.
The changes will not cause an LSP violation in case of inheritance
and can be made for parent/child classes independently of each other.
Also see: https://3v4l.org/0qM7W
* While the majority of projects will (hopefully) be able to use
nullable types/union types with null to mitigate the deprecation,
there are still projects which have a wide range of supported PHP
versions with the minimum being below PHP 7.1 (yes, WordPress I'm
looking at you).
It might be worth mentioning in the "Backward incompatible changes"
section what the options are for those projects to mitigate the deprecation.
As far as I can see, that would come down to the following options:
1. [Best option] Raise the minimum supported PHP version to 7.1,
use nullable types and remove the `null` default value.
Including a code sample like the 3v4l I posted above should
probably also help clarify the expected change to the code.
2. Removing the default value without making the type nullable.
This would be a signature change and could cause problems
if the parameter was previously optional, but that's for the
project itself to make a judgment call on.
3. For scalar and array typed parameters, changing the default
value to one which complies with the type. Again, this would
be a signature change and in this case, it could cause
problems if the parameter was previously required and not
the last parameter before optional ones, but again, that's for
the project itself to make a judgment call on.
4. Remove the type declaration + if the parameter is/was required,
remove the default value. This would be a huge step backwards,
but would still allow for making those signatures
cross-version compatible. This again, would be a signature change and this
would be one which would violate LSP in case of inheritance,
but again, that's for the project itself to make a judgment call on.
Hope I've captured all options, though not claiming completeness.
Hope this helps.
Smile,
Juliette
