PHP 7.1 added the void return type to say a function doesn't return anything useful. But every PHP function returns something, and without an explicit value that's null. This RFC from Gina Peter Banyard would make void a compile-time alias for null.
Why change it
When void arrived, return types couldn't change in child classes. PHP's type system has grown a lot since then. Return types can now be narrowed in a child class, and PHP has gained mixed (any value), never (the function never returns), and null as a standalone type.
That left void on its own branch of the type hierarchy. A method with no return type can become void or mixed in a child class, but void can't become mixed, and mixed can't become void. The RFC argues this split makes no sense and makes the type system more complicated than it needs to be.
This is valid today:
class P { public function foo() {} } class C1 extends P { public function foo(): void {} } class C2 extends P { public function foo(): mixed {} }
What changes
void becomes an alias for null, and according to the RFC only one error goes away. Right now this fails:
function foo(): void { return null; }
You get "A void function must not return a value (did you mean "return;" instead of "return null;"?)". With this RFC, that code would compile.
What it means for existing code
The RFC lists no backward compatibility breaks. Every other compile error and deprecation stays the same, and built-in extensions that declare void types would have them converted to null automatically.
Possible future work includes treating a missing type the same as mixed.
Where it stands
The page says it's under discussion. It's dated June 2, 2025, and targets PHP 8.5. The vote section still has placeholder dates, the poll has no votes, and the implementation is listed as "TBD."
We list it as inactive because the page hasn't changed since June 2025 and no vote was ever held. Its PHP 8.5 target has since shipped.