Hello Marc, Op di 17 feb 2026 om 08:40 schreef Marc B. <[email protected]>: > I'm with Roman here as well. > Yes, it's a BC break, but as Roman suggested, there would be a > deprecation phase before and forbidden only in PHP 9. This should give > enough time to adopt.
This RFC explicitly wants to reduce the BC impact to a minimum as stated in the prologue. Changing the return type declaration implicitly to void breaks that goal. The "Unaffected calling the parent constructor example" would become affected by "void" return type. If someone wants to follow the "void" path after this RFC, that's still possible. For the new "void" RFC it doesn't matter whether this RFC gets accepted or rejected. > > Also, you are talking about the constructor only, which is ok, but I > believe the destructor needs to be discussed as well and mentioned in > the RFC. > I have mentioned the __destruct() destructor in the Rejected Features chapter. Because: - The details of the destructor are completely different; it is called if the zval reference count reaches 0 and is called by the garbage collector. - Also the destructor does not have security-sensitive impact when returning values. - Also, the use of destructors is very unusual; I never use them. - This requires a separate RFC. Kind regards, Mirco Babin
