Re: [IDEA for RFC] let the "new" operator fail when the __construct() function returns a value.

From: Date: Sun, 08 Mar 2026 16:33:04 +0000
Subject: Re: [IDEA for RFC] let the "new" operator fail when the __construct() function returns a value.
References: 1 2 3 4 5 6 7 8  Groups: php.internals 
Request: Send a blank email to internals+get-130271@lists.php.net to get a copy of this message
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] <imsop.php@rwec..co.uk> wrote: > On 7 March 2026 21:31:19 GMT, "Tim Düsterhus" <tim@bastelstu.be> 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] >

« previous php.internals (#130271) next »