Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122237
To: internals@lists.php.net
References: <kii8EchCRNKJRI1IgoTQGYbxr2d0_BNN6dm4QrEFnWNaWLaH68cG-GioF5j6ebhIJv5wAVKdHojWk5XJqk9z_yL4cA0Fmb1KD0P19VrCiXU=@gpb.moe>
Message-ID: <65B08579.6000801@adviesenzo.nl>
Date: Wed, 24 Jan 2024 04:35:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: <kii8EchCRNKJRI1IgoTQGYbxr2d0_BNN6dm4QrEFnWNaWLaH68cG-GioF5j6ebhIJv5wAVKdHojWk5XJqk9z_yL4cA0Fmb1KD0P19VrCiXU=@gpb.moe>
Content-Type: multipart/alternative;
 boundary="------------090102070402060904040007"
Subject: Re: [PHP-DEV] [RFC] Deprecate implicitly nullable parameter type
From: php-internals_nospam@adviesenzo.nl (Juliette Reinders Folmer)

--------------090102070402060904040007
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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

--------------090102070402060904040007--