| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| rfc:void_return_type [2015/10/14 20:44] – v0.2 ajf | rfc:void_return_type [2017/09/22 13:28] (current) – external edit 127.0.0.1 |
|---|
| ====== PHP RFC: Void Return Type ====== | ====== PHP RFC: Void Return Type ====== |
| * Version: 0.2 | * Version: 0.2.1 |
| * Date: 2015-02-14 (v0.1), 2015-10-14 (v0.2, revival) | * Date: 2015-02-14 (v0.1, later withdrawn), 2015-10-14 (v0.2, revival) |
| * Author: Andrea Faulds, ajf@ajf.me | * Author: Andrea Faulds, ajf@ajf.me |
| * Status: Under Discussion as of 2015-02-14, previously Withdrawn on 2015-02-15 | * Status: Implemented (PHP 7.1) |
| * First Published at: http://wiki.php.net/rfc/void_return_type | * First Published at: http://wiki.php.net/rfc/void_return_type |
| |
| |
| Moreover, IDEs and other tools can warn the user when the return value of a void function is being used. It isn't strictly necessary for the language itself to cover this. | Moreover, IDEs and other tools can warn the user when the return value of a void function is being used. It isn't strictly necessary for the language itself to cover this. |
| | |
| | ==== Why call it void and not null? ==== |
| | |
| | Some have suggested that the return type be named ''null'' instead, since (as previously mentioned) PHP implicitly produces null as the result value for functions which don't explicitly return something, so ''void'' would be almost the same as just enforcing that a function returns null. Plus, ''void'' might suggest a function that can't be used in an expression, whereas ''null'' wouldn't. Also, ''void'' would be a new "type" in a sense, whereas ''null'' is preëxisting. |
| | |
| | The main reason to choose ''void'' over ''null'' is that it is the customary name to use for such a return type. We already use ''void'' rather than ''null'' when documenting functions in PHP, both built-in and userland functions: PHP's function prototypes in source code ([[https://github.com/php/php-src/blob/b00a315806ca1ac24b3e1ff97764f9813ad664e6/ext/standard/var.c#L227|e.g.]]), the PHP manual ([[http://php.net/manual/en/function.var-dump.php|e.g.]]) and phpDocumentor's docblock format ([[http://phpdoc.org/docs/latest/guides/types.html#keywords|see definition]]) all use ''void''. In addition, Hack, a PHP-derived and -compatible language which adds its own typing system, [[http://docs.hhvm.com/manual/en/hack.annotations.types.php|also uses void]]. This is just looking at existing PHP practice; most contemporary programming languages use ''void'' here. Some of these ([[https://en.wikipedia.org/wiki/Void_type#In_C_and_C.2B.2B|C, Objective-C and C++]], [[http://docs.oracle.com/javase/specs/jls/se8/html/jls-8.html#jls-Result|Java]], [[https://msdn.microsoft.com/en-us/library/yah0tteb.aspx|C#]], etc.) prohibit the use of a void function in an expression, but note that others ([[http://www.typescriptlang.org/Content/TypeScript%20Language%20Specification.pdf|TypeScript]], [[http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/specialTypes.html#void|ActionScript]], [[https://developer.apple.com/library/watchos/documentation/Swift/Conceptual/Swift_Programming_Language/Functions.html|Swift]]) //do// allow void functions in expressions, just as PHP does, by making them implicitly return some unit type. Since ''void'' seems to be the most popular choice for such a return type, both in PHP and elsewhere, why should we name it something different? There's no precedent for it and the name doesn't seem to have been an issue until now. |
| | |
| | The other reason is that ''void'' more clearly conveys that the function is supposed to not return a value, rather than return null specifically. |
| |
| ===== Backward Incompatible Changes ===== | ===== Backward Incompatible Changes ===== |
| |
| Like the names reserved by the [[rfc:scalar_type_hints_v5|Scalar Type Declarations]] and [[rfc:reserve_more_types_in_php_7|Reserve More Types in PHP 7]] RFCs, the ''void'' return type does not become a reserved word proper, but is instead restricted from use in class and interface names. This avoids confusion while minimising backwards-compatibility issues. I do not expect that ''Void'' is a very common class name, and so the backwards-compatibility impact should be limited. | Like the names reserved by the [[rfc:scalar_type_hints_v5|Scalar Type Declarations]] and [[rfc:reserve_more_types_in_php_7|Reserve More Types in PHP 7]] RFCs, the ''void'' return type does not become a reserved word proper, but is instead prohibited from use as the name of a class or interface. This avoids confusion while minimising backwards-compatibility issues. I do not expect that ''Void'' is a very common class name, and so the backwards-compatibility impact should be limited. |
| |
| ===== Proposed PHP Version(s) ===== | ===== Proposed PHP Version(s) ===== |
| This is proposed for the next minor version of PHP, currently PHP 7.1. | This is proposed for the next minor version of PHP, currently PHP 7.1. |
| |
| ===== Proposed Voting Choices ===== | ===== Vote ===== |
| |
| As this is a language change, a 2/3 majority is required. The vote is a straight Yes/No vote for accepting the RFC and merging the patch. | As this is a language change, a 2/3 majority is required. The vote is a straight Yes/No vote for accepting the RFC and merging the patch. |
| | |
| | Voting started 2015-10-29 and ended <del>10</del> 11 days later on 2015-11-09. |
| | |
| | <doodle title="Accept the Void Return Type RFC for PHP 7.1 and merge patch into master?" auth="ajf" voteType="single" closed="true"> |
| | * Yes |
| | * No |
| | </doodle> |
| |
| ===== Patches and Tests ===== | ===== Patches and Tests ===== |
| |
| There is a patch for php-src's master branch with tests: https://github.com/php/php-src/pull/1084 | There is a patch for php-src's master branch with tests: https://github.com/php/php-src/pull/1576 |
| |
| There is currently no patch for the language specification. | There is also a patch for the language specification's master branch with tests: https://github.com/php/php-langspec/pull/150 |
| |
| ===== Implementation ===== | ===== Implementation ===== |
| | |
| | The patch for the Zend Engine was merged into php-src master here: https://github.com/php/php-src/commit/366ba41334870f325f248d8e486e3ebf8bafb984 |
| | |
| | The patch for the language specification was merged into master here: https://github.com/php/php-langspec/commit/ad1a8bdba48ed23f118fe743f6930d1d57cd8042 |
| | |
| | The feature will go into PHP 7.1. |
| | |
| After the project is implemented, this section should contain | 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 | - a link to the PHP manual entry for the feature |
| |
| ===== Changelog ===== | ===== Changelog ===== |
| |
| | * v0.2.1 - Add subsection explaining name choice |
| * v0.2 - Revived, cleaned up proposal and rationale, added compile-time checking | * v0.2 - Revived, cleaned up proposal and rationale, added compile-time checking |
| * v0.1.1 - Detailed implicit null return value | * v0.1.1 - Detailed implicit null return value |
| * v0.1 - Initial version | * v0.1 - Initial version |