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. > 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". > 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. Thanks for your answer, Nicolas >
