An earlier RFC added the pipe operator, |>, which passes a value through a chain of functions that reads left to right. If you want to return the result, though, return still has to go at the very start of the line. This RFC from Vadim Dvorovenko lets you put return at the end of the chain instead.

How it looks

// Today
return "Hello World" |> strlen(...);

// With this RFC
"Hello World" |> strlen(...) |> return;

expr |> return means the same thing as return expr. Here's a longer chain:

"Hello World"
    |> htmlentities(...)
    |> str_split(...)
    |> (fn($x) => array_map(strtoupper(...), $x))
    |> return;

Why it helps

The RFC argues that code is easiest to read when it flows in one direction. A pipe chain reads top to bottom, but a return at the start makes you jump back up to see what happens to the result. In a long chain, that can mean scrolling. Putting return last keeps the whole statement in reading order.

What stays invalid

These are errors today, and they'll stay errors:

$x |> foo() |> return |> bar(); // nothing can come after return
fn() => $x |> return;           // arrow functions only take expressions
return $x |> return;
$x |> return $x;

Each one fails when PHP parses the file.

What it means for existing code

Nothing breaks, since using |> with return is a syntax error today. The RFC says it should compile to the same bytecode as a normal return, so there's no performance cost. Editors, linters and other tools would need to learn the new syntax.

A later RFC might do the same thing for throw. That would be a separate proposal, because throw works a little differently.

Where it stands

It has been under discussion since January 2026 and targets the next PHP 8.x release. The vote on the page is a placeholder with no votes cast.