Re: [IDEA for RFC] let the "new" operator fail when the __construct() function returns a value.
| From: | Pierre Joye | 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]
>