Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130271
Precedence: list
MIME-Version: 1.0
References: <CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com>
 <0ece40da-762a-4190-9cc8-23ff432fd441@bastelstu.be> <CAFgk54=JDdpYH42btk5Rn7GpNibNOAyPGzJu7c+Jh17PNKSP9g@mail.gmail.com>
 <565970ab3a667958c340a9094d53357b@bastelstu.be> <CAFgk54=AzM9gzaaEcie0f8_j6AKRdNeaeoXEWe8EPvyFEH5xMA@mail.gmail.com>
 <CAFgk54kfUwb+w2iegBp_65qFK38wL9gNNp5xWJtGkCdJSsr0sg@mail.gmail.com>
 <e7905fe0-e7b3-4241-86fd-a52fa082f362@bastelstu.be> <583462DA-F68D-454D-98D5-F286ECFB1318@rwec.co.uk>
In-Reply-To: <583462DA-F68D-454D-98D5-F286ECFB1318@rwec.co.uk>
Date: Sun, 8 Mar 2026 23:33:04 +0700
Message-ID: <CAEZPtU5JHsfTbgAHza84KBtkrugeGg0-JcQPO9mEJsyThkmJEw@mail.gmail.com>
Subject: Re: [PHP-DEV] [IDEA for RFC] let the "new" operator fail when the
 __construct() function returns a value.
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f0c884064c85d733"
From: pierre.php@gmail.com (Pierre Joye)

--000000000000f0c884064c85d733
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@rwec=
.co.uk>
wrote:

> On 7 March 2026 21:31:19 GMT, "Tim D=C3=BCsterhus" <tim@bastelstu.be> wro=
te:
> >I plan to pick this up based on my suggested implementation and have jus=
t
> 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]
>

--000000000000f0c884064c85d733
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div>Hi Tim,=C2=A0 Rowan,</div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">for that specific return value in constructor, as i men=
tioned earlier, I think it does not even require=C2=A0 a rfc. Not even a de=
preciation addition but as a courtesy.=C2=A0</div><div dir=3D"auto"><br></d=
iv><div dir=3D"auto">I did not check the git history but I am pretty sure i=
t is a forgotten part when moving away from class name construct,=C2=A0 and=
 it is clearly documented as : void=C2=A0</div><div dir=3D"auto"><br></div>=
<div dir=3D"auto"><a href=3D"https://www.php.net/manual/en/language.oop5.de=
con.php">https://www.php.net/manual/en/language.oop5.decon.php</a></div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">this is a typical case the rfc a=
bout not overdoing rfcs or bc for bug fixes or similar.</div><div dir=3D"au=
to"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">best,</div><div=
>--</div><div data-smartmail=3D"gmail_signature">Pierre<br><br>@pierrejoye =
| <a href=3D"http://www.libgd.org" target=3D"_blank">http://www.libgd.org</=
a></div></div><br><div class=3D"gmail_quote gmail_quote_container"><div dir=
=3D"ltr" class=3D"gmail_attr">On Sun, Mar 8, 2026, 10:13=E2=80=AFPM Rowan T=
ommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.php@rwec.c=
o.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 7 March 2026=
 21:31:19 GMT, &quot;Tim D=C3=BCsterhus&quot; &lt;<a href=3D"mailto:tim@bas=
telstu.be" target=3D"_blank" rel=3D"noreferrer">tim@bastelstu.be</a>&gt; wr=
ote:<br>
&gt;I plan to pick this up based on my suggested implementation and have ju=
st added the proposal as a stub to the PHP 8.6 bulk deprecation RFC at<br>
&gt;<br>
&gt;<a href=3D"https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_retu=
rning_a_value_from_construct" rel=3D"noreferrer noreferrer" target=3D"_blan=
k">https://wiki.php.net/rfc/deprecations_php_8_6#deprecate_returning_a_valu=
e_from_construct</a><br>
<br>
Hi Tim, <br>
<br>
I appreciate this is mostly just a stub to revisit later, but for the recor=
d I think this should have its own RFC. There&#39;s a risk of these bulk RF=
Cs becoming a way to bypass our normal process, since each section has much=
 less detail than would be required for a standalone RFC.<br>
<br>
In this case, you will be revisiting a topic where a previous RFC was rejec=
ted, so it&#39;s important that there&#39;s a clear rationale of why either=
 this is a different proposal, or the previous arguments no longer apply.<b=
r>
<br>
Regards,<br>
<br>
Rowan Tommins<br>
[IMSoP]<br>
</blockquote></div>

--000000000000f0c884064c85d733--