On Mon, 2 Feb 2026 at 09:57, Rob Landers <[email protected]> wrote: > > > > On Mon, Feb 2, 2026, at 04:46, Morgan wrote: > > On 2026-02-02 13:18, Rob Landers wrote: > > > > > > > > From an observability point of view, you lost me when you said return's > > type is "never". > > > > https://3v4l.org/plpIf#v8.5.0 <https://3v4l.org/plpIf#v8.5.0> > > > > We can clearly see the type is "null", unless you mean something more > > abstract? > > > I'm referring to the expression's value as it may exist in a larger > expression, primarily for type checking. To use the match{} example, > what value does $split get when $len == 1, because in that case the > statement boils down to "$split = return false;"? Evaluation never comes > back to the assignment to assign $split anything, in the same way that a > call to a function of type never shouldn't see evaluation coming back to > the call site. > > If $split were something still visible after function return ("$o->p"), > since the assignment didn't happen it would still have its previous value. > > But as I alluded and you noted, this wouldn't be observable: the caller > gets the value of the return expression's operand (or null, if no such > operand was provided, in which case why are you trying to see the value > of a function of type void?) > > If you were doing static analysis, making the type of a return > expression that of its operand could be an issue: in that match{} > example there is no assertion that $split is supposed to contain a > boolean. Let's say it's supposed to be an int. "int|bool" would be an > incorrect inference; since never is a bottom type and thus a subtype of > every type, "int|never" == "int". > > On the other hand, "int|Exception" is just as invalid, but throwing > exceptions from inside expressions is pretty well-behaved; I think > modelling return's semantics the same way would work, but I don't know > enough of the internals to make that judgement. > > Basically, the type of a return expression would be the type of a throw. > > > I would say the weirdest thing about making return an expression boils down to where it could then be used: > > myFunc(return 123); > > $arr = [1, 2, return 3]; > > 1 + 2 + return 3 > > Are just some basic examples. As I mentioned in the other thread about this, it would make finding method/function returns like hunting for a needle in a haystack. > > — Rob
I think all those examples actually make sense. `return <expr>` would itself become an expression, which means you could use it anywhere, all those places already support `throw`. example: https://3v4l.org/nqbkU static analyzers would be able to warn about unreachable code and `never` being used within expressions: https://mago.carthage.software/playground#019c1d99-449c-e1bf-2517-726d0b9f9b5f
