rfc:void_return_type

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:void_return_type [2015/10/29 00:16] – ...oh god I really need to proofread ajfrfc:void_return_type [2017/09/22 13:28] (current) – external edit 127.0.0.1
Line 3: Line 3:
   * Date: 2015-02-14 (v0.1, later withdrawn), 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: In Voting+  * 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
  
Line 95: Line 95:
 ==== Why call it void and not null? ==== ==== 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.+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 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.
Line 113: Line 113:
 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 ends <del>10</del> 11 days later on 2015-11-09.+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="false">+<doodle title="Accept the Void Return Type RFC for PHP 7.1 and merge patch into master?" auth="ajf" voteType="single" closed="true">
    * Yes    * Yes
    * No    * No
Line 124: Line 124:
 There is a patch for php-src's master branch with tests: https://github.com/php/php-src/pull/1576 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
  
rfc/void_return_type.1446077761.txt.gz · Last modified: 2017/09/22 13:28 (external edit)