Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130134
Precedence: list
MIME-Version: 1.0
References: <CAFgk54k4NkUrUkMD=HE1TkowDJb55X9B7hcCa7vxGUbAfQhv8w@mail.gmail.com>
 <1f25d77e-224b-40d6-bf19-18dfdfc9de54@rwec.co.uk> <CAFgk54knVsdNQbVxVL43qyA3vkQrMHZt=ATfuiDCD4qJa6MPVg@mail.gmail.com>
 <453bc043-b4ee-423e-9561-55510f5c20a7@rwec.co.uk> <CAFgk54nimvF4UC6KOxaGg-v5hFazt1sNTyyJ-bkqHy6Xm5nOHA@mail.gmail.com>
 <e4d2994a-ae1e-4f33-89c3-67c5df99f1d3@rwec.co.uk> <CAFgk54kmk8uYjF8RcsOGKAyvBZNn2tYEd9D1PVK2prfeU=pF5A@mail.gmail.com>
 <6412E222-9B0F-4139-A6F9-7D0C686197BF@rwec.co.uk> <CAFgk54=S1KjPwgHy_Qy7xtGbVvfHkd4SEMZ+o1WhzaVHZQ7ncw@mail.gmail.com>
 <88259C1D-1D31-4FB1-8CA8-1F704378467D@rwec.co.uk> <CAFgk54kZzBbEfxOc71ztXk9LG6DpoKHroepm_Db5MN5_7-VV2A@mail.gmail.com>
In-Reply-To: <CAFgk54kZzBbEfxOc71ztXk9LG6DpoKHroepm_Db5MN5_7-VV2A@mail.gmail.com>
Date: Mon, 23 Feb 2026 18:20:25 +0700
Message-ID: <CAEZPtU7FMc7pjsWT59T=hh8Pwa_3+a+=7gEgNQhK-AZGbBw+GQ@mail.gmail.com>
Subject: Re: [PHP-DEV] [IDEA for RFC] let the "new" operator fail when the
 __construct() function returns a value.
To: Mirco Babin <mirco.babin@gmail.com>
Cc: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a77c3a064b7bf5b1"
From: pierre.php@gmail.com (Pierre Joye)

--000000000000a77c3a064b7bf5b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 23, 2026, 4:23=E2=80=AFPM Mirco Babin <mirco.babin@gmail.com> w=
rote:

> Op za 21 feb 2026 om 17:28 schreef Rowan Tommins [IMSoP] <
> imsop.php@rwec.co.uk>:
> >
> > On 20 February 2026 16:07:01 GMT, Mirco Babin <mirco.babin@gmail.com>
> wrote:
> > >Failing early is not always possible. The compiler can not always infe=
re
> > >the correct return type.
> >
> > PHP defines "void" separately from "null", precisely so that the compil=
er
> > doesn't need to infer anything about the returned value. All it has to =
do
> > is distinguish "return;" from "return some_expression;"
> >
> > Example: https://3v4l.org/cTaBP
> >
>
> That is a very good find. Are the following claims correct?
>
>
>    In all cases it would be a compile error, because the compiler only
>    checks "return something;" vs. "return;".
>
>    It would never throw a TypeError at runtime.


that's correct,  as the return statement will have an expression, it will
be detected.

absence of return is equivalent to return; as well.

you can see it using the ast extension, that may help you to see what can
or cannot be check at compile vs runtime, I general.  the engine does many
compile time checks but not as much as a static analyzers or a compiled
language can do, but things similar to this are cheap and usually done.


best,
--
Pierre

@pierrejoye | http://www.libgd.org

--000000000000a77c3a064b7bf5b1
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><div><br></div><div><br></div><br><br><br><div class=
=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr=
">On Mon, Feb 23, 2026, 4:23=E2=80=AFPM Mirco Babin &lt;<a href=3D"mailto:m=
irco.babin@gmail.com">mirco.babin@gmail.com</a>&gt; wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">Op za 21 feb 2026 om 17:28 schreef Rowan Tommins [I=
MSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk" target=3D"_blank" rel=3D"=
noreferrer">imsop.php@rwec.co.uk</a>&gt;:<br>
&gt;<br>
&gt; On 20 February 2026 16:07:01 GMT, Mirco Babin &lt;<a href=3D"mailto:mi=
rco.babin@gmail.com" target=3D"_blank" rel=3D"noreferrer">mirco.babin@gmail=
.com</a>&gt; wrote:<br>
&gt; &gt;Failing early is not always possible. The compiler can not always =
infere<br>
&gt; &gt;the correct return type.<br>
&gt;<br>
&gt; PHP defines &quot;void&quot; separately from &quot;null&quot;, precise=
ly so that the compiler<br>
&gt; doesn&#39;t need to infer anything about the returned value. All it ha=
s to do<br>
&gt; is distinguish &quot;return;&quot; from &quot;return some_expression;&=
quot;<br>
&gt;<br>
&gt; Example: <a href=3D"https://3v4l.org/cTaBP" rel=3D"noreferrer noreferr=
er" target=3D"_blank">https://3v4l.org/cTaBP</a><br>
&gt;<br>
<br>
That is a very good find. Are the following claims correct?<br>
<br><br>
=C2=A0 =C2=A0In all cases it would be a compile error, because the compiler=
 only<br>
=C2=A0 =C2=A0checks &quot;return something;&quot; vs. &quot;return;&quot;.<=
br>
<br>
=C2=A0 =C2=A0It would never throw a TypeError at runtime.</blockquote></div=
></div><div dir=3D"auto"><br></div><div dir=3D"auto">that&#39;s correct,=C2=
=A0 as the return statement will have an expression, it will be detected.</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">absence of return is equi=
valent to return; as well.=C2=A0</div><div dir=3D"auto"><br></div><div dir=
=3D"auto">you can see it using the ast extension, that may help you to see =
what can or cannot be check at compile vs runtime, I general.=C2=A0 the eng=
ine does many compile time checks but not as much as a static analyzers or =
a compiled language can do, but things similar to this are cheap and usuall=
y done.</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div d=
ir=3D"auto">best,</div><div dir=3D"auto">--</div><div dir=3D"auto">Pierre</=
div><div dir=3D"auto"><br></div><div dir=3D"auto">@pierrejoye | <a href=3D"=
http://www.libgd.org">http://www.libgd.org</a></div><div dir=3D"auto"></div=
></div>

--000000000000a77c3a064b7bf5b1--