Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129973
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Mon, 02 Feb 2026 01:18:32 +0100
To: internals@lists.php.net
Message-ID: <d2b6fed6-56c5-482a-89e9-955fc3fcb48c@app.fastmail.com>
In-Reply-To: <bfcfa113-01cd-42d8-923e-edc896c6b548@varteg.nz>
References: <bfcfa113-01cd-42d8-923e-edc896c6b548@varteg.nz>
Subject: Re: [PHP-DEV] Return expression
Content-Type: multipart/alternative;
 boundary=37631e07667b44e489d07643f290cde8
From: rob@bottled.codes ("Rob Landers")

--37631e07667b44e489d07643f290cde8
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Mon, Feb 2, 2026, at 00:41, Morgan wrote:
> Just piping up in a sort of pre-discussion way to see if there might b=
e=20
> any interest in making "return" an expression - in the same way and fo=
r=20
> many (though not all) of the same reasons that "throw" was made an=20
> expression in 8.0.
>=20
> Both return and throw "end the current execution"; the difference is=20
> that "throw" does it because things went bad, while "return" does it=20
> because things went well and nothing more needs doing.
>=20
> So, for example:
>=20
>=20
> $result =3D query('foo') ?? return false;
>=20
> rather than
>=20
> if(($result =3D query('foo')) =3D=3D=3D null) return false;
>=20
>=20
> or
>=20
> $split =3D match($len) {
> 0 =3D> throw new UnderflowException("Unexpectedly empty"),
> 1 =3D> return false,
> 2,3,5,7 =3D> return true,
> 4,6,8,9 =3D> $this->smol($len),
> default =3D> $this->foo($len, $scale)
> };
>=20
>=20
> instead of
>=20
> if($len =3D=3D=3D 0)
> throw new UnderflowException("Unexpectedly empty");
> if($len =3D=3D=3D 1)
> return false;
> if($len =3D=3D=3D 2 || $len =3D=3D=3D 3 || $len =3D=3D=3D 5 || $len =3D=
=3D=3D 7)
> return true;
> if($len =3D=3D=3D 4 || $len =3D=3D=3D 6 || $len =3D=3D=3D 8 || $len =3D=
=3D=3D 9)
> $split =3D $this->smol($len);
> else
> $split =3D $this->foo($len, $scale);
>=20
> .
>=20
> A return expression works entirely by its side-effects (passing contro=
l=20
> and the value of its operand back to the calling scope); its own type =
is=20
> "never".
>=20
> The weirdest behaviour I can see at this early stage is the main way i=
t=20
> deviates from "reasons to have throw as an expression":
>=20
> fn($x) =3D> return $x * 2
>=20
> would work, but not in the way you'd think it does; it expands out to
>=20
> function($x) {
> return return $x * 2;
> }
>=20
> Which (like "throw throw") is syntactically legal, but the redundant=20
> operator is redundant. Semantically, however, it could be problematic:=20
> The anonymous function's return type is technically "never", since tha=
t=20
> is what the type of its return statement's operand is. But that return=20
> statement never(!) completes, because said operand causes the function=20
> to end prematurely, causing the numeric value to be returned instead.=20
> And, of course, a numeric value is not a "never".
>=20
> What this will do to type declarations I don't know. But checking that=20
> the body of an arrow function is a return expression and at least=20
> notifying the author that it's redundant could be done.
>=20
> This I guess would also impact ordinary return statements: they are no=
w=20
> expressions that evaluate to "never", and that could have consequences=20
> for how return types and return type declarations are determined in=20
> general...
>=20
> If necessary, I suppose, the type of a return expression could be that=20
> of its operand - it's just that no-one will ever see it because=20
> execution is always abandoned before then.

Hi Morgan,

From an observability point of view, you lost me when you said return's =
type is "never".

https://3v4l.org/plpIf#v8.5.0

We can clearly see the type is "null", unless you mean something more ab=
stract?

Are you thinking of return as a function call, so you could write it out=
 like:

return(return($x*2))

I guess in that case, you could conceptually think of its arguments as f=
unction that returns what to return? Thus the above is just sugar for:

return function() {
  return fn() =3D> $x*2;
}

Which would just collapse down to:

return $x*2;

I think you could handwave it down to that. The removal of the infinite =
functions is just an optimisation.

=E2=80=94 Rob
--37631e07667b44e489d07643f290cde8
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 00:41, Morgan wrote:</div><blo=
ckquote type=3D"cite" id=3D"qt" style=3D""><div>Just piping up in a sort=
 of pre-discussion way to see if there might be&nbsp;</div><div>any inte=
rest in making "return" an expression - in the same way and for&nbsp;</d=
iv><div>many (though not all) of the same reasons that "throw" was made =
an&nbsp;</div><div>expression in 8.0.</div><div><br></div><div>Both retu=
rn and throw "end the current execution"; the difference is&nbsp;</div><=
div>that "throw" does it because things went bad, while "return" does it=
&nbsp;</div><div>because things went well and nothing more needs doing.<=
/div><div><br></div><div>So, for example:</div><div><br></div><div><br><=
/div><div>$result =3D query('foo') ?? return false;</div><div><br></div>=
<div>rather than</div><div><br></div><div>if(($result =3D query('foo')) =
=3D=3D=3D null) return false;</div><div><br></div><div><br></div><div>or=
</div><div><br></div><div>$split =3D match($len) {</div><div>0 =3D&gt; t=
hrow new UnderflowException("Unexpectedly empty"),</div><div>1 =3D&gt; r=
eturn false,</div><div>2,3,5,7 =3D&gt; return true,</div><div>4,6,8,9 =3D=
&gt; $this-&gt;smol($len),</div><div>default =3D&gt; $this-&gt;foo($len,=
 $scale)</div><div>};</div><div><br></div><div><br></div><div>instead of=
</div><div><br></div><div>if($len =3D=3D=3D 0)</div><div>throw new Under=
flowException("Unexpectedly empty");</div><div>if($len =3D=3D=3D 1)</div=
><div>return false;</div><div>if($len =3D=3D=3D 2 || $len =3D=3D=3D 3 ||=
 $len =3D=3D=3D 5 || $len =3D=3D=3D 7)</div><div>return true;</div><div>=
if($len =3D=3D=3D 4 || $len =3D=3D=3D 6 || $len =3D=3D=3D 8 || $len =3D=3D=
=3D 9)</div><div>$split =3D $this-&gt;smol($len);</div><div>else</div><d=
iv>$split =3D $this-&gt;foo($len, $scale);</div><div><br></div><div>.</d=
iv><div><br></div><div>A return expression works entirely by its side-ef=
fects (passing control&nbsp;</div><div>and the value of its operand back=
 to the calling scope); its own type is&nbsp;</div><div>"never".</div><d=
iv><br></div><div>The weirdest behaviour I can see at this early stage i=
s the main way it&nbsp;</div><div>deviates from "reasons to have throw a=
s an expression":</div><div><br></div><div>fn($x) =3D&gt; return $x * 2<=
/div><div><br></div><div>would work, but not in the way you'd think it d=
oes; it expands out to</div><div><br></div><div>function($x) {</div><div=
>return return $x * 2;</div><div>}</div><div><br></div><div>Which (like =
"throw throw") is syntactically legal, but the redundant&nbsp;</div><div=
>operator is redundant. Semantically, however, it could be problematic:&=
nbsp;</div><div>The anonymous function's return type is technically "nev=
er", since that&nbsp;</div><div>is what the type of its return statement=
's operand is. But that return&nbsp;</div><div>statement never(!) comple=
tes, because said operand causes the function&nbsp;</div><div>to end pre=
maturely, causing the numeric value to be returned instead.&nbsp;</div><=
div>And, of course, a numeric value is not a "never".</div><div><br></di=
v><div>What this will do to type declarations I don't know. But checking=
 that&nbsp;</div><div>the body of an arrow function is a return expressi=
on and at least&nbsp;</div><div>notifying the author that it's redundant=
 could be done.</div><div><br></div><div>This I guess would also impact =
ordinary return statements: they are now&nbsp;</div><div>expressions tha=
t evaluate to "never", and that could have consequences&nbsp;</div><div>=
for how return types and return type declarations are determined in&nbsp=
;</div><div>general...</div><div><br></div><div>If necessary, I suppose,=
 the type of a return expression could be that&nbsp;</div><div>of its op=
erand - it's just that no-one will ever see it because&nbsp;</div><div>e=
xecution is always abandoned before then.</div></blockquote><div><br></d=
iv><div>Hi Morgan,</div><div><br></div><div>From an observability point =
of view, you lost me when you said return's type is "never".</div><div><=
br></div><div><a href=3D"https://3v4l.org/plpIf#v8.5.0">https://3v4l.org=
/plpIf#v8.5.0</a></div><div><br></div><div>We can clearly see the type i=
s "null", unless you mean something more abstract?</div><div><br></div><=
div>Are you thinking of return as a function call, so you could write it=
 out like:</div><div><br></div><div>return(return($x*2))</div><div><br><=
/div><div>I guess in that case, you could conceptually think of its argu=
ments as function that returns what to return? Thus the above is just su=
gar for:</div><div><br></div><div>return function() {</div><div>&nbsp; r=
eturn fn() =3D&gt; $x*2;</div><div>}</div><div><br></div><div>Which woul=
d just collapse down to:</div><div><br></div><div>return $x*2;</div><div=
><br></div><div>I think you could handwave it down to that. The removal =
of the infinite functions is just an optimisation.</div><div><br></div><=
div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--37631e07667b44e489d07643f290cde8--