Hey Andreas, That is incorrect. Adding an explicit `: void` does change behavior since only then the check (whether something is being returned) is enforced. This allows PHP 8 projects to take advantage of this enforcement while being respective to older codebases.
And well, the explicit `: void` declaration also helps your code to be more consistent with other methods ;) Without an explicit `: void` return type declaration, `void` rules are not enforced on constructors/destructors and will not be until PHP 9.0 (which will probably release in 5 years). Moreover, saying "it forces organisations, frameworks or the php-fig group to introduce yet another coding convention" is a complete exaggeration. In fact, even now there are no PSR conventions that specify how and when to write parameter/return/property type hints. Also, it's important to understand that PHP libraries are really really slow at starting to **depend** on new PHP versions. It will probably take a few good years (if not more) until first few libraries start requiring PHP 8.0. As a matter of fact, even Symfony framework is still requiring PHP 7.2.5 and cannot take advantage of its newer features (e. g. typed properties). Last but not least, just to reiterate, the `: void` return type is optional and you don't need to specify it. Best regards, Benas On Thu, Jun 18, 2020, 7:02 PM Andreas Hennings <andr...@dqxtech.net> wrote: > Hi > > The RFC introduces what I call a "meaningless choice", by making something > possible that is currently illegal, but which does not change behavior. > https://3v4l.org/daeEm > > It forces organisations, frameworks or the php-fig group to introduce yet > another coding convention to decide whether or not there should be a ": > void" declaration on constructors. > > I am ok with restricting the use of "return *;" inside a constructor. > But I don't like allowing the ": void" declaration. > > Greetings > > On Thu, 18 Jun 2020 at 17:18, Benas IML <benas.molis....@gmail.com> wrote: > >> Hey Bob, >> >> Magic methods are **never** supposed to be called directly (even more if >> that method is a constructor or a destructor). If that's not the case, >> it's >> just plain bad code. But by enforcing these rules, we make sure that less >> of that (bad code) is written and as a result, we make PHP code less >> bug-prone and easier to debug. That's also most likely the reason why >> "ensure magic methods' signature" RFC opted in to validate `__clone` >> method's signature and ensure that it has `void` return type. >> >> Just for the sake of making sure that you understand what I mean, here are >> a couple of examples that show that no magic method is ever supposed to be >> called directly: >> ```php >> // __toString >> (string) $object; >> >> // __invoke >> $object(); >> >> // __serialize >> serialize($object); >> ``` >> >> Moreover, by validating constructors/destructors and allowing an explicit >> `void` return type declaration, we are becoming much more consistent >> (something that PHP is striving for) with other magic methods (e. g. >> `__clone`). >> >> Also, saying that "sometimes you have valid information to pass from the >> parent class" is quite an overstatement. After analyzing most of the 95 >> Composer packages that had a potential BC break, I found out that either >> they wanted to return early (that is still possible to do using `return;`) >> or they added a `return something;` for no reason. Thus, no libraries >> actually returned something useful and valid from a constructor (as they >> shouldn't). >> >> Last but certainly not least, constructors have one and only one >> responsibility - to initialize an object. Whether you read Wikipedia's or >> PHP manual's definition, a constructor does just that. It initializes. So, >> the PHP manual is perfectly correct and documents the correct return type >> that a constructor should have. >> >> Best regards, >> Benas >> >> On Thu, Jun 18, 2020, 4:06 PM Bob Weinand <bobw...@hotmail.com> wrote: >> >> > > 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 >> >
