Thanks everybody for the replies. > However, I am also fine if the void return value is only enforced when the > void return > type is declared. Additionally, we could emit a deprecation notice/warning > when > there is no return type declaration, but a value is returned. I think this > would be > a nice way to immediately give people the possibility to disallow a return > value, > while being respectful for older code bases.
Completely agreed. I'll update the RFC to reflect this as well. We should allow newer codebases to enforce `void` rules on constructors/destructors by allowing to explicitly declare return type as `void`. Meanwhile, we should throw a deprecation warning, if the constructor/destructor is returning a non-void value and doesn't have an explicit `: void` declaration. Then, presumably in PHP 9, in addition to explicit `: void`, also enforce `void` rules implicitly altogether. Best regards, Benas On Wed, 17 Jun 2020 at 11:31, Máté Kocsis <kocsismat...@gmail.com> wrote: >> >> This PR should also address all of Máté's concerns since it makes >> constructors and destructors always return `void` (even when no explicit >> `void` return type is specified). > > > To be clear, my main concern was that declaring a void return type shouldn't > be > allowed, unless it's actually enforced. Now, it's all fine because you stated > your > intentions :) > > However, I am also fine if the void return value is only enforced when the > void return > type is declared. Additionally, we could emit a deprecation notice/warning > when > there is no return type declaration, but a value is returned. I think this > would be > a nice way to immediately give people the possibility to disallow a return > value, > while being respectful for older code bases. > > Regards, > Máté > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
