> > I think that Larry's and Rowan's replies on the original discussion thread >> really well explained as to why it makes sense to allow an explicit `void` >> return type, so I'll just quote them instead ;) >> >> Larry: >> > I see this in the same category as __toString(). >> > > I read those yes, but there are subtle yet critical differences to me: > > in PHP < 8, 1. the return-type of __toString is already enforced by the > engine (just not by the type-system, but the end result is the same) and 2. > it is already allowed to add the "string" return type to the method. > > for constructors/destructors, neither 1. nor 2. are true: they *do*not* > allow any return type and they don't check the return value. > > This means that the change on __toString is mostly transparent (only the > exact error message is different), while the proposed change is not. It > will have a cost for the community, and my opinion is that this cost is not > worth it. >
Well, for `__clone` neither 1 nor 2 are true as well. But as of PHP 8.0 it will be allowed to declare an explicit `void` return type on `__clone`. Thus, this will have a higher cost for the community since this behavior will be quite inconsistent with constructors/destructors which do not allow to declare an explicit return type. > > Any constructor returning non-void right now is Doing It Wrong(tm) >> > > That's precisely what I read as "gratuitous strictness" (no offense to > anyone, I respect this opinion.) > Especially when this might become "enforced". > That is rather subjective. Adding an explicit `void` return type allows to clearly show developer's intention to not return values from a constructor/destructor. While some people might not see any value in this, I personally do (and many others too). Moreover, as mentioned before, adding an explicit `void` return type causes the check to already be done in PHP 8.0. Which otherwise implicitly will only be done in PHP 8.1/9.0. > > >> Since some internals told me that PHP doesn't follow semver strictly, it >> would make sense to enforce the check in PHP 8.1 already. >> > > I invite you to read https://wiki.php.net/rfc/releaseprocess where this > is detailed. > Here is the relevant excerpt: "x.y.z to x.y+1.z" => "Backward > compatibility must be kept". > > A dedicated vote in a specific RFC cannot overrule this policy AFAIK. > See Nikita's reply. But if more internals find this controversial, I can close the secondary vote, that's okay with me. > Thanks for your answer, > Nicolas > Best regards, Benas >
