Re: [RFC] [VOTE] Make constructors and destructors return void

> > 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 >