Hi Tim, Rowan, for that specific return value in constructor, as i mentioned earlier, I think it does not even require a rfc. Not even a depreciation addition but as a courtesy.
I did not check the git history but I am pretty sure it is a forgotten part when moving away from class name construct, and it is clearly documented as : void https://www.php.net/manual/en/language.oop5.decon.php this is a typical case the rfc about not overdoing rfcs or bc for bug fixes or similar. best, -- Pierre @pierrejoye | http://www.libgd.org On Sun, Mar 8, 2026, 10:13 PM Rowan Tommins [IMSoP] <[email protected]> wrote: > On 7 March 2026 21:31:19 GMT, "Tim Düsterhus" <[email protected]> wrote: > >I plan to pick this up based on my suggested implementation and have just > added the proposal as a stub to the PHP 8.6 bulk deprecation RFC at > > > > > https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_returning_a_value_from_construct > > Hi Tim, > > I appreciate this is mostly just a stub to revisit later, but for the > record I think this should have its own RFC. There's a risk of these bulk > RFCs becoming a way to bypass our normal process, since each section has > much less detail than would be required for a standalone RFC. > > In this case, you will be revisiting a topic where a previous RFC was > rejected, so it's important that there's a clear rationale of why either > this is a different proposal, or the previous arguments no longer apply. > > Regards, > > Rowan Tommins > [IMSoP] >
