> Am 17.06.2020 um 01:10 schrieb Benas IML <benas.molis....@gmail.com>: > > Hey internals, > > This is a completely refined, follow-up RFC to my original RFC. Based on the > feedback I have received, this PR implements full validation and implicitly > enforces `void` rules on constructors/destructors while also allowing to > declare an **optional** explicit `void` return type. Note, that there is a > small but justifiable BC break (as stated by the RFC). > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas
Hey Benas, I do not see any particular benefit from that RFC. Regarding what the manual states - the manual is wrong there and thus should be fixed in the manual. This is not an argument for changing engine behaviour. Sometimes a constructor (esp. of a parent class) or destructor may be called manually. Sometimes you have valid information to pass from the parent class. With your RFC an arbitrary restriction is introduced necessitating an extra method instead. In general that RFC feels like "uh, __construct and __destruct are mostly void, so let's enforce it … because we can"? On these grounds and it being an additional (albeit mostly small) unnecessary BC break, I'm not in favor of that RFC. Bob -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
