Hey Andreas, It seems that you actually haven't read my reply carefully enough.
> But this distinction would only apply in PHP 8. And the only difference here is whether returning a value is just deprecated or fully illegal. > In PHP 9, constructors with ": void" would be the same as without ": void". So long term it will become a "meaningless choice". > > Or what am I missing? The "allowance" of `void` return type will help: - to be more explicit. - to enforce `void` rules on constructors/destructors (in PHP 8). - to be more consistent with other methods (which is what people like the most about allowing `void` on ctor/dtor based on r/php). - to be more consistent with the documentation. > Except consistency with existing constructors in other packages which choose to not add ": void" to constructors. > > Either it is enforced in a "code convention", or it is up to every single developer and team, and we get silly arguments between developers in code review whether or not this should be added. Or we get git noise because one developer adds those declarations, and another removes them. I find these comments of yours to make completely no sense since most of the additions to PHP will create some sort of silly arguments between developers. A best example would be the `mixed` type. Based on what you have said, this pseudo type will create inconsistencies because some libraries will have parameters explicitly declared as `mixed` while others - won't. It will also create arguments between developers on whether they should use it or not. Moving on, let's take the `void` type (implemented in PHP 7.1) as another great example! Laravel and Symfony (both depend on PHP 7.2) don't use it while other libraries - do. So, as I understand based on your comments, this is creating inconsistencies and arguments between developers. Some say `void` should be added, some say not. Some libraries declare it, some don't. Moving on, attributes. If you go onto Reddit, you can see that the crowd is divided 50/50. Some believe that attributes are bad and say that they will use functions (for "adding" metadata) instead. Others prefer attributes and will use those. You can literally find people bashing each other for their preference. So that is creating heated arguments AND possibly future inconsistencies between different people/libraries. It's not possible to be "politically" neutral. Every single feature/code style is used by some group of people and isn't used by another. So next time please be more pragmatic. > So if you want to support PHP 7, you cannot add ": void". > If you only care about PHP 9, you don't need to add ": void" because it is pointless. > > Any convention would probably discourage it to be more universally usable. This is a completely contradicting statement. Just a few sentences ago you said that there will be silly arguments between people. But now as I understand, most conventions will probably discourage the explicit `: void` return type on constructors/destructors. Thus, since most people follow conventions, there will be little-to-no arguments. > Exactly my point. "Optional" means people will make arbitrary choices and argue about it, or look for a convention. Already addressed this. Best regards, Benas On Thu, Jun 18, 2020, 11:15 PM Andreas Hennings <andr...@dqxtech.net> wrote: > > On Thu, 18 Jun 2020 at 18:33, Benas IML <benas.molis....@gmail.com> wrote: > >> 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. >> >> Ok. I read more carefully now. > > But this distinction would only apply in PHP 8. And the only difference > here is whether returning a value is just deprecated or fully illegal. > In PHP 9, constructors with ": void" would be the same as without ": void". > So long term it will become a "meaningless choice". > > Or what am I missing? > > > >> And well, the explicit `: void` declaration also helps your code to be >> more consistent with other methods ;) >> > > Except consistency with existing constructors in other packages which > choose to not add ": void" to constructors. > > >> >> 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. >> > > Either it is enforced in a "code convention", or it is up to every single > developer and team, and we get silly arguments between developers in code > review whether or not this should be added. Or we get git noise because one > developer adds those declarations, and another removes them. > > >> >> 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). >> > > So if you want to support PHP 7, you cannot add ": void". > If you only care about PHP 9, you don't need to add ": void" because it is > pointless. > > Any convention would probably discourage it to be more universally usable. > > > >> >> Last but not least, just to reiterate, the `: void` return type is >> optional and you don't need to specify it. >> > > Exactly my point. "Optional" means people will make arbitrary choices and > argue about it, or look for a convention. > > Greetings > Andreas > > > >> >> Best regards, >> Benas >> >
