rfc:nullable_typehints

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:nullable_typehints [2014/04/26 13:52]
levim
rfc:nullable_typehints [2017/09/22 13:28] (current)
Line 1: Line 1:
-====== PHP RFC: Declaring Nullable Types ====== +This RFC has moved to [[https://wiki.php.net/rfc/nullable_types]].
-  * Version: 0.1 +
-  * Date: 2014-04-10  +
-  * Author: Levi Morrison <levim@php.net> +
-  * Status: Draft +
-  * First Published at: https://wiki.php.net/rfc/nullable_typehints +
- +
-===== Introduction ===== +
-This RFC proposes new syntax to allow type declarations to also accept <php>null</php> without a default value.  +
- +
-Consider the function: +
- +
-<PHP> +
-function foo(DateTime $time, $a) {} +
-</PHP> +
- +
-In this situation you are not allowed to pass <php>null</php> for the<php>$time</php> parameter; this proposal allows you do pass <php>null</php> without using a default (''= null'').  +
- +
-===== Proposal ===== +
-This proposal adds a mark ''?'' to indicate that a type can also be <php>null</php>. This is allowed for any declared type including <php>array</php> and <php>callable</php>+
- +
-The ''?'' marker can be placed on any parameter position, provided it does not violate inheritance rules: +
-<PHP> +
-function f(?callable $p, $a) {} // valid +
-</PHP> +
- +
-Note that nullable parameters are required; you cannot omit the parameter. +
- +
-==== Inheritance in parameters ==== +
- +
-The ''?'' marker cannot be removed in a sub-class; it can be added if not present in a super-class. This behavior is consistent with the Liskov substitution principle. +
- +
-<PHP> +
-// Valid use: loosening the nullable marker in a parameter: +
-interface Fooable { +
-    function foo(Fooable $f); +
-+
-interface Foo extends Fooable { +
-    function foo(?Fooable $f); +
-+
-</PHP> +
- +
-<PHP> +
-// Invalid use: tightening the nullable marker in a parameter: +
-interface Fooable { +
-    function foo(?Fooable $f); +
-+
-interface Foo extends Fooable { +
-    function foo(Fooable $f); +
-+
-</PHP> +
- +
-==== Return Types ==== +
-If the [[rfc:returntypehinting|RFC for Declaring Return Types]] passes, then nullable types would be extended to return types as well; this is a major motivator for introducing this new syntax as return types cannot specify a null default to get around the type check. +
- +
-Here's an example of a binary tree class that uses the ''?'' marker for both parameter and return types: +
- +
-<PHP> +
-// Possible usage of ? modifier for both parameters and return types +
-class BinaryTree { +
-    public $value; +
-    private $right; +
-    private $left; +
- +
-    function right(): ?BinaryTree { +
-        return $this->left; +
-    } +
-    function left(): ?BinaryTree { +
-        return $this->left; +
-    } +
- +
-    function setRight(?BinaryTree $t) { +
-        $this->right = $t; +
-    } +
-    function setLeft(?BinaryTree $t) { +
-        $this->left = $t; +
-    } +
-+
-</PHP> +
- +
-Note that it doesn't really make sense to call <php>$btree->setLeft();</php> without a parameter; the ''?'' better reflects the ability to accept ''BinaryTree'' or ''null'' than a default value of ''null'' in this case. +
- +
-=== Inheritance in Return Types === +
- +
-In return types the ''?'' marker would behave differently during inheritance than a parameter type would. In a return type, the null marker can be removed by a subclass, but it cannot be added: +
-<PHP> +
-interface Fooable { +
-    function foo(): ?Fooable; +
-+
-interface StrictFooable extends Fooable { +
-    function foo(): Fooable; // valid +
-+
-</PHP> +
-<PHP> +
-interface Fooable { +
-    function foo(): Fooable; +
-+
-interface LooseFooable extends Fooable { +
-    function foo(): ?Fooable; // invalid +
-+
-</PHP> +
- +
-==== Differences from Default Parameters ==== +
-The null marker does not have a default; it does not default to <php>null</php>. The following snippet would result in an error: +
-<PHP> +
-function f(?callable $p) {} +
-f(); // invalid; function f does not have a default +
-</PHP> +
- +
-===== Proposed PHP Version(s) ===== +
-5.7 or 6.0 +
- +
-===== RFC Impact ===== +
- +
-==== To Backward Incompatibility ==== +
-TODO +
- +
-==== To SAPIs ==== +
-TODO  +
- +
-==== To Existing Extensions ==== +
-TODO  +
- +
-==== New Constants ==== +
-This RFC does not propose any new constants or ini defaults. +
- +
-==== php.ini Defaults ==== +
-If there are any php.ini settings then list: +
-  * hardcoded default values +
-  * php.ini-development values +
-  * php.ini-production values +
- +
-===== Open Issues ===== +
-Make sure there are no open issues when the vote starts! +
- +
-===== Unaffected PHP Functionality ===== +
-List existing areas/features of PHP that will not be changed by the RFC. +
- +
-This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise. +
- +
-===== Future Scope ===== +
-TODO +
- +
-===== Proposed Voting Choices ===== +
-This RFC modifies the PHP language syntax and therefore requires a two-third majority of votes. +
- +
-===== Patches and Tests ===== +
-There is currently no patch. +
- +
-===== Implementation ===== +
-TODO +
- +
-After the project is implemented, this section should contain  +
-  - the version(s) it was merged to +
-  - a link to the git commit(s) +
-  - a link to the PHP manual entry for the feature +
- +
-===== References ===== +
-TODO +
rfc/nullable_typehints.1398520335.txt.gz · Last modified: 2017/09/22 13:28 (external edit)