Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision |
rfc:mixed_type_v2 [2020/04/20 01:04] – Updated text for new version. danack | rfc:mixed_type_v2 [2020/04/20 01:18] – added clarity to BC break. danack |
---|
====== 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> |
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. |
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#L94) 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. | 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: |
==== 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. |
==== 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> |
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 ==== |
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_7) keyword 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. |
| |
| |
===== 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 ===== |
Not analyzed. | Not analyzed. |
| |
===== Proposed Voting Choices | ===== Proposed Voting Choices ===== |
| |
Add ''mixed'' as a type to be used as parameter, return and class property types - yes/no. | Add ''mixed'' as a type to be used as parameter, return and class property types - yes/no. |