rfc:make_ctor_ret_void

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:make_ctor_ret_void [2020/07/06 19:58] – updated RFC moliatarfc:make_ctor_ret_void [2020/07/22 15:29] (current) – updated RFC moliata
Line 3: Line 3:
   * Author: Benas Seliuginas, <benas.molis.iml@gmail.com>   * Author: Benas Seliuginas, <benas.molis.iml@gmail.com>
   * Target version: PHP 8.0   * Target version: PHP 8.0
-  * Status: Under Discussion+  * Status: Declined
  
 Large credit for this RFC goes to Michael Voříšek who initially reported the bug and created a draft-- patch. Large credit for this RFC goes to Michael Voříšek who initially reported the bug and created a draft-- patch.
Line 109: Line 109:
 } }
 </code> </code>
 +
 +===== Why allow void return type on constructors/destructors? =====
 +
 +**Enforcing ''void'' rules on constructors/destructors implictly but not allowing to declare an explicit type is going to create inconsistencies**.
 +
 +It's key to understand that constructors and destructors in PHP don't work the same way that they do in other languages. First of all, unlike in other languages, constructors and destructors are rather normal functions in PHP and can be called directly i. e. through ''$object-><nowiki>__</nowiki>construct()'' and ''$object-><nowiki>__</nowiki>destruct()''. Adding an explicit ''void'' return type acts as an extra marker that takes the reader from 99% certain to 100% that these functions are not supposed to return anything. This also aligns with the [[https://www.php.net/manual/en/language.oop5.decon.php|PHP manual]] which states that constructors/destructors have a return type of ''void'' and the Zen of Python's 2nd principle ("Explicit is better than implicit"). Thus, saying that other languages don't have a concept of return types for constructors does not make much sense in PHP's case.
 +
 +Rowan Tommins comment on the internals mailing list should also be taken into consideration:
 +"//The way I look at it, constructors are mostly declared like a normal
 +method - they use the keyword "function"; can be marked public, private,
 +protected, abstract, and final; and can have a parameter list, with
 +types and defaults - so the surprising thing is that there is a special
 +rule <nowiki>*forbidding*</nowiki> them from having a return specifier//".
 +
 +Another argument that is used against allowing explicit ''void'' return type is that it's going to create code-style wars and is duplicate information. But arguably, everyone also already knows what functions such as ''<nowiki>__</nowiki>toString()'' return. You know it's going to be a string. That's its whole purpose. It would be surprising to see any code style forbidding that. Moreover, as of PHP 8.0, constructors and destructors will be the only methods that are not allowed to have a return type. This will be quite inconsistent given that ''<nowiki>__clone</nowiki>'' magic method will be able to have an explicit ''void'' return type even though both object construction and object cloning work in a similar fashion.
  
 ===== Vote ===== ===== Vote =====
-PrimaryMake constructors and destructors return void? Yes/no.+==== Primary ==== 
 +<doodle title="Make constructors/destructors return void?" auth="moliata" voteType="single" closed="true"> 
 +   Yes 
 +   * No 
 +</doodle>
  
-SecondaryAllow void return type on constructors/destructors? Yes/no.+==== Secondary ==== 
 +<doodle title="Allow void return type on constructors/destructors?" auth="moliata" voteType="single" closed="true"> 
 +   Yes 
 +   * No 
 +</doodle>
  
 ===== Implementation ===== ===== Implementation =====
 [[https://github.com/php/php-src/pull/5727|GitHub Pull Request]] [[https://github.com/php/php-src/pull/5727|GitHub Pull Request]]
rfc/make_ctor_ret_void.1594065492.txt.gz · Last modified: 2020/07/06 19:58 by moliata