rfc:nullable_typehints

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:nullable_typehints [2014/05/03 17:47] – Grammar. levimrfc:nullable_typehints [2017/09/22 13:28] (current) – external edit 127.0.0.1
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 marker ''?'' 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->right; +
-    } +
-    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) ===== +
-This RFC targets 5.7 or 6.0, whichever comes first. +
- +
-===== RFC Impact ===== +
- +
-==== To Backward Incompatibility ==== +
-This RFC maintains backwards compatibility. This RFC does not deprecate the default value syntax. +
- +
-==== To SAPIs ==== +
-This RFC has no impact to SAPIs. +
- +
-==== To Existing Extensions ==== +
-TODO  +
- +
-==== New Constants ==== +
-This RFC does not propose any new constants or ini defaults. +
- +
-===== Open Issues ===== +
-Make sure there are no open issues when the vote starts! +
- +
-===== Unaffected PHP Functionality ===== +
-This RFC does not deprecate the default value syntax. While there is some overlap of features between it and this RFC, they serve different purposes. As such, the default value syntax will remain. +
- +
-===== 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.1399139260.txt.gz · Last modified: 2017/09/22 13:28 (external edit)

Page Tools