Hi Am 2026-05-09 16:09, schrieb Rowan Tommins [IMSoP]:
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'm really struggling to find something meaningful to write down, because to me this very much feels like an obvious fix. I think (b) most closely fits here with the overall theme of the direction PHP is going being “point out mistakes rather than silently continuing doing something the user likely didn't intend”. I feel this is similar to https://wiki.php.net/rfc/policy-exempt-type-value-error-bc-policy where we already decided that pointing out invalid inputs is preferable to “just do something”.
(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.)
Increasing the time between substantially identical proposals makes sense to me, 6 months could mean that the same proposal comes up twice for the same PHP version. But I think that after several years it's reasonable to just agree that “PHP today is different from the PHP back then” and have another vote on an otherwise unchanged proposal.
Best regards Tim Düsterhus
