On Sat, May 9, 2026, at 9:09 AM, Rowan Tommins [IMSoP] wrote: > On 08/05/2026 09:44, Tim Düsterhus wrote: >> Hi >> >> following Rowan’s request from the earlier “let the "new" operator >> fail when the __construct( ) function returns a value” discussion [1], >> I have now created a dedicated RFC to deprecate returning values from >> __construct() and __destruct(). >> >> Please find the RFC text at: >> https://wiki.php.net/rfc/deprecate-return-value-from-construct > > > Hi Tim, > > Thanks for writing this up. > > In terms of the proposal, I am thoroughly in favour. Deliberate use of a > return value here is rare, and refactoring to use a non-magic helper > method should generally be fairly easy. > It's also in line with restrictions added to other magic methods - e.g. > calling __toString() directly could return any value until 8.0, but it > now acts as though declared with a return type of "string". > > In terms of the RFC text, though, I think there should be more than a > "see also" link to the previous RFC at > https://wiki.php.net/rfc/make_ctor_ret_void This went to a vote and was > declined (with a majority in favour, but not the required > super-majority), so I think the new RFC should explain how either a) the > new proposal is different from the old one; or b) the circumstances are > different from when they were last voted. > > (I think our policy wording on this [1] probably needs to be tightened > up slightly; as written, it implies that a failed proposal could be > brought to vote unchanged every 6 months, until the author got the > result they wanted.) > > [1] > https://github.com/php/policies/blob/main/feature-proposals.rst#resurrecting-rejected-proposals > > Regards, > > -- > Rowan Tommins > [IMSoP]
I agree with Rowan on both fronts. +1 on the feature, but also +1 on better explanation of why this attempt is better/different/more worthy of support than previous attempts. --Larry Garfield
