rfc:mixed_type_v2

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:mixed_type_v2 [2020/04/20 01:04] – Updated text for new version. danackrfc:mixed_type_v2 [2020/05/22 14:22] (current) kocsismate
Line 1: Line 1:
 ====== PHP RFC: Mixed Type v2 ====== ====== PHP RFC: Mixed Type v2 ======
-  * Version: 0.1+  * Version: 0.9
   * Date: 2020-03-23   * Date: 2020-03-23
   * Author: Máté Kocsis <kocsismate@php.net>, Danack<danack@php.net>   * Author: Máté Kocsis <kocsismate@php.net>, Danack<danack@php.net>
   * Based on previous RFC by: Michael Moravec   * Based on previous RFC by: Michael Moravec
-  * Target Version: 8.0 +  * Status: Implemented 
-  * Status: In Draft +  * Implementation: https://github.com/php/php-src/pull/5313
-  * Implementation:+
   * First Published at: https://wiki.php.net/rfc/mixed_type_v2   * First Published at: https://wiki.php.net/rfc/mixed_type_v2
  
 ===== Introduction ===== ===== Introduction =====
  
-With the addition of scalar types in PHP 7, nullables in 7.1, `objectin 7.2, and lastly, union types in 8.0, people writing PHP code can explicitly declare type information for most function parameters, function returns, as well as class properties.+With the addition of scalar types in PHP 7, nullables in 7.1, object in 7.2, and lastly, union types in 8.0, people writing PHP code can explicitly declare type information for most function parameters, function returns, as well as class properties.
  
 However, PHP has not always supported types, and most probably it will always allow to omit type information. But this leads to the problem that its meaning is ambiguous when type information is missing: However, PHP has not always supported types, and most probably it will always allow to omit type information. But this leads to the problem that its meaning is ambiguous when type information is missing:
  
-* the type is a specific type, but the programmer forgot to declare it. +  * the type is a specific type, but the programmer forgot to declare it. 
-* the type is a specific type, but the programmer omitted it to keep compatibility with an older PHP version +  * the type is a specific type, but the programmer omitted it to keep compatibility with an older PHP version 
-* the type is not currently expressible in PHP's type system, and so no type could be specified. +  * the type is not currently expressible in PHP's type system, and so no type could be specified. 
-* for return types, it is not clear if the function will or will not return a value, other than null.+  * for return types, it is not clear if the function will or will not return a value, other than null.
  
 An explicit ''mixed'' type would allow people to add types to parameters, class properties and function returns to indicate that the type information wasn't forgotten about, it just can't be specified more precisely, or the programmer explicitly decided not to do so. An explicit ''mixed'' type would allow people to add types to parameters, class properties and function returns to indicate that the type information wasn't forgotten about, it just can't be specified more precisely, or the programmer explicitly decided not to do so.
Line 24: Line 23:
 Currently, ''mixed'' can only be used in PHPDoc-based type hints to give more context about a type, but this is a suboptimal solution, since it also has the same problems that comments generally have. Currently, ''mixed'' can only be used in PHPDoc-based type hints to give more context about a type, but this is a suboptimal solution, since it also has the same problems that comments generally have.
  
-One prominent example where the ''mixed'' type is extensively used in PHPDoc is the [stubs of PHP's own standard library](https://github.com/php/php-src/blob/dfd0acf0d722fbbebeab349b0d4366dd8f30bbee/ext/standard/basic_functions.stub.php#L94with which type information is defined for internal functions. If we had the native ''mixed'' type, we could provide more precise reflection information for users about functions that accept or return any type.+One prominent example where the ''mixed'' type is extensively used in PHPDoc is the [[https://github.com/php/php-src/blob/dfd0acf0d722fbbebeab349b0d4366dd8f30bbee/ext/standard/basic_functions.stub.php#L94|stubs of PHP's own standard library]] with which type information is defined for internal functions. If we had the native ''mixed'' type, we could provide more precise reflection information for users about functions that accept or return any type.
  
 Additionally, the ''mixed'' pseudo-type is used widely in the PHP manual: Additionally, the ''mixed'' pseudo-type is used widely in the PHP manual:
Line 40: Line 39:
 ==== LSP, Covariance and Contravariance ==== ==== LSP, Covariance and Contravariance ====
  
-The proposal conforms to the [Liskov Substituion Priniciple](https://en.wikipedia.org/wiki/Liskov_substitution_principle), when performing signature checks for inheritance.+The proposal conforms to the [[https://en.wikipedia.org/wiki/Liskov_substitution_principle|Liskov Substituion Priniciple]], when performing signature checks for inheritance.
  
-Since 7.4 PHP allows [covariant returns and contravariant parameters](https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters).+Since 7.4 PHP allows [[https://wiki.php.net/rfc/covariant-returns-and-contravariant-parameters|covariant returns and contravariant parameters]].
  
 PHP allows contravariance (aka type widening) for parameter types to obey the LSP principle. A subclass may use a 'wider' aka less specific type in place of the inherited type for a parameter. PHP allows contravariance (aka type widening) for parameter types to obey the LSP principle. A subclass may use a 'wider' aka less specific type in place of the inherited type for a parameter.
Line 124: Line 123:
 ==== Property types are invariant ==== ==== Property types are invariant ====
  
-Following the [typed properties RFC](https://wiki.php.net/rfc/typed_properties_v2#inheritance_and_variance), all property types are invariant.+Following the [[typed properties RFC|https://wiki.php.net/rfc/typed_properties_v2#inheritance_and_variance]], all property types are invariant.
  
 <code php> <code php>
Line 218: Line 217:
 Currently this only affects inheritance in classes. Currently this only affects inheritance in classes.
  
-If/when PHP gains the abilties to declare [function signatures as types](https://github.com/Danack/RfcCodex/blob/master/typedef_callables.md), rather than just the generic ''callable'' type this signature checking should work for those signature checks also.+If/when PHP gains the abilties to declare [[https://github.com/Danack/RfcCodex/blob/master/typedef_callables.md|function signatures as types]], rather than just the generic ''callable'' type this signature checking should work for those signature checks also.
  
 ==== Signature checking of function when no return type present ==== ==== Signature checking of function when no return type present ====
Line 272: Line 271:
 //INVALID - Fatal error: Mixed types cannot be nullable, null is already part of the mixed type. //INVALID - Fatal error: Mixed types cannot be nullable, null is already part of the mixed type.
 function bar(): ?mixed {} function bar(): ?mixed {}
 +</code>
 +
 +
 +
 +==== Explicit returns ==== 
 +
 +When using mixed as a return type, a value must be explicitly returned from the function, otherwise a TypeError will be thrown.
 +
 +<code php>
 +function foo(): mixed {}
 +
 +foo();
 +
 +// Uncaught TypeError: Return value of foo() must be of 
 +// the type mixed, none returned
 +</code>
 +
 +This is consistent with the existing behaviour for other return types.
 +
 +<code php>
 +function bar(): ?int {}
 +bar();
 +// Uncaught TypeError: Return value of bar() must be of 
 +// the type int or null, none returned
 +
 </code> </code>
  
Line 284: Line 308:
 This RFC proposes ''mixed'' rather than ''any'' since ''mixed'' has been used widely in the PHP ecosystem already (e.g. the PHP manual, static analysis tools like PHPStan and Psalm, IDEs). This RFC proposes ''mixed'' rather than ''any'' since ''mixed'' has been used widely in the PHP ecosystem already (e.g. the PHP manual, static analysis tools like PHPStan and Psalm, IDEs).
  
-Also, choosing to use ''any'' would likely have a slightly bigger BC break, as ''mixed'' is a [soft reserved](https://wiki.php.net/rfc/reserve_even_more_types_in_php_7keyword since PHP 7, but ''any'' hasn't had any warnings against using it as a class name.+Also, choosing to use ''any'' would likely have a slightly bigger BC break, as ''mixed'' is a [[https://wiki.php.net/rfc/reserve_even_more_types_in_php_7|soft reserved]] keyword since PHP 7, but ''any'' hasn't had any warnings against using it as a class name.
  
  
Line 295: Line 319:
 ===== Backward Incompatible Changes ===== ===== Backward Incompatible Changes =====
  
-Since PHP 7.0, ''mixed'' is a 'soft' reserved word.+Since PHP 7.0, ''mixed'' is a 'soft' reserved word. This RFC would prevent the use of ''mixed'' as a class name if it is passed.
  
 ===== To SAPIs ===== ===== To SAPIs =====
Line 306: Line 330:
 Not analyzed. Not analyzed.
  
-===== Proposed Voting Choices+===== Vote =====  
 +The vote starts on 2020-05-07 and ends on 2020-05-21 12:00 UTC. The vote requires 2/3 majority to be accepted.
  
-Add ''mixed'' as a type to be used as parameter, return and class property types - yes/no.+<doodle title="Add mixed as a type to be used as parameter, return and class property types?" auth="kocsismate" voteType="single" closed="true"> 
 +   * Yes 
 +   * No 
 +</doodle>
  
  
rfc/mixed_type_v2.txt · Last modified: 2020/05/22 14:22 by kocsismate