Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129975
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 02 Feb 2026 09:56:00 +0100
To: internals@lists.php.net
Message-ID: <918fbb69-9bb3-42f9-a3df-d1d7fdbaa65e@app.fastmail.com>
In-Reply-To: <78e9c0ed-8c30-499f-8597-7352f6fb8d51@varteg.nz>
References: <bfcfa113-01cd-42d8-923e-edc896c6b548@varteg.nz>
 <d2b6fed6-56c5-482a-89e9-955fc3fcb48c@app.fastmail.com>
 <78e9c0ed-8c30-499f-8597-7352f6fb8d51@varteg.nz>
Subject: Re: [PHP-DEV] Return expression
Content-Type: multipart/alternative;
 boundary=cb1dc0696b934353bbd0a466a0c986bd
From: rob@bottled.codes ("Rob Landers")

--cb1dc0696b934353bbd0a466a0c986bd
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Mon, Feb 2, 2026, at 04:46, Morgan wrote:
> On 2026-02-02 13:18, Rob Landers wrote:
> >=20
> >=20
> >=20
> >  From an observability point of view, you lost me when you said retu=
rn's=20
> > type is "never".
> >=20
> > https://3v4l.org/plpIf#v8.5.0 <https://3v4l.org/plpIf#v8.5.0>
> >=20
> > We can clearly see the type is "null", unless you mean something mor=
e=20
> > abstract?
> >=20
> I'm referring to the expression's value as it may exist in a larger=20
> expression, primarily for type checking. To use the match{} example,=20
> what value does $split get when $len =3D=3D 1, because in that case th=
e=20
> statement boils down to "$split =3D return false;"? Evaluation never c=
omes=20
> back to the assignment to assign $split anything, in the same way that=
 a=20
> call to a function of type never shouldn't see evaluation coming back =
to=20
> the call site.
>=20
> If $split were something still visible after function return ("$o->p")=
,=20
> since the assignment didn't happen it would still have its previous va=
lue.
>=20
> But as I alluded and you noted, this wouldn't be observable: the calle=
r=20
> gets the value of the return expression's operand (or null, if no such=20
> operand was provided, in which case why are you trying to see the valu=
e=20
> of a function of type void?)
>=20
> If you were doing static analysis, making the type of a return=20
> expression that of its operand could be an issue: in that match{}=20
> example there is no assertion that $split is supposed to contain a=20
> boolean. Let's say it's supposed to be an int. "int|bool" would be an=20
> incorrect inference; since never is a bottom type and thus a subtype o=
f=20
> every type, "int|never" =3D=3D "int".
>=20
> On the other hand, "int|Exception" is just as invalid, but throwing=20
> exceptions from inside expressions is pretty well-behaved; I think=20
> modelling return's semantics the same way would work, but I don't know=20
> enough of the internals to make that judgement.
>=20
> Basically, the type of a return expression would be the type of a thro=
w.

I would say the weirdest thing about making return an expression boils d=
own to where it could then be used:

myFunc(return 123);

$arr =3D [1, 2, return 3];

1 + 2 + return 3

Are just some basic examples. As I mentioned in the other thread about t=
his, it would make finding method/function returns like hunting for a ne=
edle in a haystack.

=E2=80=94 Rob
--cb1dc0696b934353bbd0a466a0c986bd
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div><br></div><d=
iv><br></div><div>On Mon, Feb 2, 2026, at 04:46, Morgan wrote:</div><blo=
ckquote type=3D"cite" id=3D"qt" style=3D""><div>On 2026-02-02 13:18, Rob=
 Landers wrote:</div><div>&gt;&nbsp;</div><div>&gt;&nbsp;</div><div>&gt;=
&nbsp;</div><div>&gt;&nbsp; From an observability point of view, you los=
t me when you said return's&nbsp;</div><div>&gt; type is "never".</div><=
div>&gt;&nbsp;</div><div>&gt;&nbsp;<a href=3D"https://3v4l.org/plpIf#v8.=
5.0">https://3v4l.org/plpIf#v8.5.0</a> &lt;<a href=3D"https://3v4l.org/p=
lpIf#v8.5.0">https://3v4l.org/plpIf#v8.5.0</a>&gt;</div><div>&gt;&nbsp;<=
/div><div>&gt; We can clearly see the type is "null", unless you mean so=
mething more&nbsp;</div><div>&gt; abstract?</div><div>&gt;&nbsp;</div><d=
iv>I'm referring to the expression's value as it may exist in a larger&n=
bsp;</div><div>expression, primarily for type checking. To use the match=
{} example,&nbsp;</div><div>what value does $split get when $len =3D=3D =
1, because in that case the&nbsp;</div><div>statement boils down to "$sp=
lit =3D return false;"? Evaluation never comes&nbsp;</div><div>back to t=
he assignment to assign $split anything, in the same way that a&nbsp;</d=
iv><div>call to a function of type never shouldn't see evaluation coming=
 back to&nbsp;</div><div>the call site.</div><div><br></div><div>If $spl=
it were something still visible after function return ("$o-&gt;p"),&nbsp=
;</div><div>since the assignment didn't happen it would still have its p=
revious value.</div><div><br></div><div>But as I alluded and you noted, =
this wouldn't be observable: the caller&nbsp;</div><div>gets the value o=
f the return expression's operand (or null, if no such&nbsp;</div><div>o=
perand was provided, in which case why are you trying to see the value&n=
bsp;</div><div>of a function of type void?)</div><div><br></div><div>If =
you were doing static analysis, making the type of a return&nbsp;</div><=
div>expression that of its operand could be an issue: in that match{}&nb=
sp;</div><div>example there is no assertion that $split is supposed to c=
ontain a&nbsp;</div><div>boolean. Let's say it's supposed to be an int. =
"int|bool" would be an&nbsp;</div><div>incorrect inference; since never =
is a bottom type and thus a subtype of&nbsp;</div><div>every type, "int|=
never" =3D=3D "int".</div><div><br></div><div>On the other hand, "int|Ex=
ception" is just as invalid, but throwing&nbsp;</div><div>exceptions fro=
m inside expressions is pretty well-behaved; I think&nbsp;</div><div>mod=
elling return's semantics the same way would work, but I don't know&nbsp=
;</div><div>enough of the internals to make that judgement.</div><div><b=
r></div><div>Basically, the type of a return expression would be the typ=
e of a throw.</div></blockquote><div><br></div><div>I would say the weir=
dest thing about making return an expression boils down to where it coul=
d then be used:</div><div><br></div><div>myFunc(return 123);</div><div><=
br></div><div>$arr =3D [1, 2, return 3];</div><div><br></div><div>1 + 2 =
+ return 3</div><div><br></div><div>Are just some basic examples. As I m=
entioned in the other thread about this, it would make finding method/fu=
nction returns like hunting for a needle in a haystack.</div><div><br></=
div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--cb1dc0696b934353bbd0a466a0c986bd--