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 be
> any interest in making "return" an expression - in the same way and for
> many (though not all) of the same reasons that "throw" was made an
> expression in 8.0.
>
> Both return and throw "end the current execution"; the difference is
> that "throw" does it because things went bad, while "return" does it
> because things went well and nothing more needs doing.
>
> So, for example:
>
>
> $result = query('foo') ?? return false;
>
> rather than
>
> if(($result = query('foo')) === null) return false;
>
>
> or
>
> $split = match($len) {
> 0 => throw new UnderflowException("Unexpectedly empty"),
> 1 => return false,
> 2,3,5,7 => return true,
> 4,6,8,9 => $this->smol($len),
> default => $this->foo($len, $scale)
> };
>
>
> instead of
>
> if($len === 0)
> throw new UnderflowException("Unexpectedly empty");
> if($len === 1)
> return false;
> if($len === 2 || $len === 3 || $len === 5 || $len === 7)
> return true;
> if($len === 4 || $len === 6 || $len === 8 || $len === 9)
> $split = $this->smol($len);
> else
> $split = $this->foo($len, $scale);
>
> .
>
> A return expression works entirely by its side-effects (passing control
> and the value of its operand back to the calling scope); its own type is
> "never".
>
> The weirdest behaviour I can see at this early stage is the main way it
> deviates from "reasons to have throw as an expression":
>
> fn($x) => return $x * 2
>
> would work, but not in the way you'd think it does; it expands out to
>
> function($x) {
> return return $x * 2;
> }
>
> Which (like "throw throw") is syntactically legal, but the redundant
> operator is redundant. Semantically, however, it could be problematic:
> The anonymous function's return type is technically "never", since that
> is what the type of its return statement's operand is. But that return
> statement never(!) completes, because said operand causes the function
> to end prematurely, causing the numeric value to be returned instead.
> And, of course, a numeric value is not a "never".
>
> What this will do to type declarations I don't know. But checking that
> the body of an arrow function is a return expression and at least
> notifying the author that it's redundant could be done.
>
> This I guess would also impact ordinary return statements: they are now
> expressions that evaluate to "never", and that could have consequences
> for how return types and return type declarations are determined in
> general...
>
> If necessary, I suppose, the type of a return expression could be that
> of its operand - it's just that no-one will ever see it because
> 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 abstract?
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 function
that returns what to return? Thus the above is just sugar for:
return function() {
return fn() => $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.
— Rob
