rfc:deprecate-implicitly-nullable-types

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:deprecate-implicitly-nullable-types [2024/01/23 15:20] – Clarify wording theodorejbrfc:deprecate-implicitly-nullable-types [2024/04/11 13:02] (current) – kocsismate
Line 1: Line 1:
 ====== PHP RFC: Deprecate implicitly nullable parameter types ====== ====== PHP RFC: Deprecate implicitly nullable parameter types ======
  
-  * Version: 0.1+  * Version: 0.2
   * Date: 2023-12-20   * Date: 2023-12-20
   * Authors: Máté Kocsis <kocsismate@php.net>, Gina Peter Banyard <girgias@php.net>   * Authors: Máté Kocsis <kocsismate@php.net>, Gina Peter Banyard <girgias@php.net>
-  * Status: Under Discussion+  * Status: Implemented
   * Target Version: PHP 8.4   * Target Version: PHP 8.4
   * Implementation: [[https://github.com/php/php-src/pull/12959|https://github.com/php/php-src/pull/12959]]   * Implementation: [[https://github.com/php/php-src/pull/12959|https://github.com/php/php-src/pull/12959]]
Line 74: Line 74:
 Deprecated: Implicitly marking parameter $var as nullable is deprecated, the explicit nullable type must be used instead Deprecated: Implicitly marking parameter $var as nullable is deprecated, the explicit nullable type must be used instead
 </PHP> </PHP>
 +
 +And remove support for implicitly nullable types in PHP 9.
  
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
Line 79: Line 81:
 Using an implicitly nullable type will emit a deprecation notice. Using an implicitly nullable type will emit a deprecation notice.
  
-There exist a variety of userland tools to automatically update implicit +==== Impact analysis and migration paths ==== 
-nullable types to explicit nullable types. + 
-One such example is the <php>nullable_type_declaration_for_default_null_value</php> +Out of the top 2000 composer packages 880 use implicitly nullable types. [2] 
-fixer from [[https://github.com/PHP-CS-Fixer/PHP-CS-Fixer|PHP-CS-Fixer]].+One explanation for such a high usage is that using implicitly nullable types 
 +was mandated by Symfony's coding style. 
 + 
 +However, there exist a variety of tools to automatically update code to use 
 +explicit nullable types from the <php>T $parameter = null</php> syntax to <php>?T $parameter = null</php>. 
 +And Symfony used one of them to migrate their codebase, and change their coding style, 
 +in anticipation of this RFC. [3] 
 + 
 +Two such tools are [[https://github.com/PHP-CS-Fixer/PHP-CS-Fixer|PHP-CS-Fixer]] 
 +with the <php>nullable_type_declaration_for_default_null_value</php> fixer, 
 +and [[https://github.com/PHPCSStandards/PHP_CodeSniffer/|PHP_CodeSniffer]] 
 +using the <php>SlevomatCodingStandard.TypeHints.NullableTypeForNullDefaultValue</php> sniff 
 +from the [[https://github.com/slevomat/coding-standard|Slevomat Coding Standard]]. 
 + 
 +It should be noted that it is possible to ignore the commit which fixes these issues from the 
 +<php>git blame</php> command since git version 2.23 via the <php>--ignore-rev</php> argument flag or the creation of a 
 +<php>.git-blame-ignore-revs</php> file which is passed to the <php>--ignore-revs-file</php> argument flag. 
 + 
 +This flag can also be automatically configured using: 
 +<code>shell 
 +git config blame.ignoreRevsFile .git-blame-ignore-revs 
 +</code> 
 + 
 +One other issue which might be revealed when converting implicitly nullable types to explicit ones 
 +without removing the default <php>null</php> value, is that an optional parameter might now exist before a mandatory one. 
 +Which will cause a secondary deprecation notice as this was [[https://github.com/php/php-src/pull/5067|deprecated in PHP 8.0]] as previously mentioned.
  
 As the <php>?T</php> syntax has existed since PHP 7.1, which is 7 years old, As the <php>?T</php> syntax has existed since PHP 7.1, which is 7 years old,
-we deem version cross compatibility to be a non-issue.+the various tools available to fix this issue automatically, 
 +and this issue being easily resolved as it requires a single change at the declaration site 
 +(instead of potentially infinite call-site changes), 
 +we deem this deprecation to be easily handled and fixed. 
 + 
 +==== Code change examples ==== 
 + 
 +The following example: 
 +<PHP> 
 +class Foo { 
 +    public function bar(int $x = null, float $y) { 
 +        // ... 
 +    } 
 +} 
 +</PHP> 
 + 
 +should end up looking like: 
 +<PHP> 
 +class Foo { 
 +    public function bar(?int $x, float $y) { 
 +        // ... 
 +    } 
 +} 
 +</PHP>
  
 ===== Version ===== ===== Version =====
Line 95: Line 145:
 As per the voting RFC a yes/no vote with a 2/3 majority is needed for this proposal to be accepted. As per the voting RFC a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.
  
-Voting started on 2024-XX-XX and will end on 2024-XX-XX.+Voting started on 2024-02-28 and will end on 2024-03-13.
    
 <doodle title="Accept Deprecate implicitly nullable parameter types RFC?" auth="girgias" voteType="single" closed="true"> <doodle title="Accept Deprecate implicitly nullable parameter types RFC?" auth="girgias" voteType="single" closed="true">
Line 105: Line 155:
  
 [1] https://externals.io/message/114007#114026 [1] https://externals.io/message/114007#114026
 +
 +[2] https://gist.github.com/kocsismate/cf3bdfbf35eb10224ee5ecd29b39656b
 +
 +[3] https://github.com/symfony/symfony/pull/53612
  
rfc/deprecate-implicitly-nullable-types.1706023242.txt.gz · Last modified: 2024/01/23 15:20 by theodorejb

Page Tools