[RFC] Transform void into an alias for null

The RFC mentions that this will now become valid:

function foo(): void {
return null;
}

But what about the opposite:

function foo(): null {
return;
}

or what Larry was trying to suggest:

function foo(): null {
print 'test';
}

$val = foo();

The result of this RFC is that the following would no longer be an error, yes?

function test(): void {
print "test";
}

// This currently gives an error, but you propose that it
// would change to set $val to null?
$val = test();

There is no error: https://3v4l.org/UD4vn

--
Anton

p.s. sorry Larry, first time I forgot that I'm answering to the mailing
list :D

I agree the type hierarchy you describe is weird, but rather than
throwing away the functionality completely, I wonder if we can make it
more consistent:

• Make "no return type declared" and "mixed" equivalent
• Make "void" a sub-type of "null", and therefore a sub-type of "mixed"

I think that null and void are semantically very different so I'd like
to suggest just making void subtype of mixed. This will both keep the
semantic meaning of void and make mixed and undeclared mean the same thing.

--
Anton

The objective is to fix a weird quirk of PHP's type system, where void lives in its own type hierarchy.
This is visible mainly in that a lack of return type is not isomorphic to a function that has a return type of mixed.

I think if "void" was added now, it would be an attribute, rather than a type. It is in effect the exact opposite of #[\NoDiscard], and distinguishes between these two cases:

interface Foo {
public function getSomething(): ?Something;
}

class MyFoo implements Foo {
public function getSomething(): null {
// My result is always null, but still meaningful to consumers of the Foo interface
return null;
}

#[\DiscardReturn]
public function doSomething(): null {
// I have no meaningful information to return; any assignment of my implicit value is a mistake
}

}

A function that always returns the same value is not meaningful to a consumer, the only exception is in a class hierarchy with an overloaded method.
But in that case the consumer expects potential other concrete values, so this point is a bit moot IMHO.
In the same way as saving the result of print() is pointless because it always returns 1, or a function that always returns true.

I agree the type hierarchy you describe is weird, but rather than throwing away the functionality completely, I wonder if we can make it more consistent:

• Make "no return type declared" and "mixed" equivalent
• Make "void" a sub-type of "null", and therefore a sub-type of "mixed"

If I've got that right, this would then be legal:

class

A

{

public

function

foo

(

)

{

}

}

class

B extends A

{

public

function

foo

(

)

: mixed

{

}

}

class

C extends B

{

public

function

foo

(

)

: null

{

}

}

class

D extends C

{

public

function

foo

(

)

: void

{

}

}

class

E extends D

{

public

function

foo

(

): never

{

}

}

That seems reasonable enough; I may have missed something important, though

Not sure if it is important, but you are missing the case where null takes part in a union type.
Your proposed change would also allow the following class hierarchy:

class

A

{

public

function

foo

(

)

{

}

}

class

B extends A

{

public

function

foo

(

)

: mixed

{

}

}

class

C extends B

{

public

function

foo

(

)

: string|int|null

{

}

}

class

D extends C

{

public

function

foo

(

)

: void

{

}

}

class

E extends D

{

public

function

foo

(

): never

{

}

}

But if people think this type hierarchy makes more sense, then sure.
I am not convinced, as I think it is a good thing PHP always returns a value from a function.
Lying about this just seems pointless and leading to misunderstandings about how the language behaves.
Best regards,
Gina P. Banyard

Hi

Am 2025-06-03 01:46, schrieb Ilija Tovilo:

IMO, these checks are useful enough not to be removed.

I agree with Ilija (and also Rowan). To me there is an important
semantic difference between “not returning anything” and “always
returning null”. I believe that void being in a distinct type
hierarchy is the right choice and when considering “untyped returns” to
be soft-deprecated / discouraged, there are no inconsistencies either.

Best regards
Tim Düsterhus

Hi Gina

RFC: https://wiki.php.net/rfc/void-as-null

After a read, I think I fundamentally disagree with the proposal. It
says (regarding the status-quo):

• void is not a subtype of a function with a mixed return type

This is laid out as a downside, but I don't think it is. Consider this
example under the specified behavior:

interface MapInterface {
public function set(string $key, mixed $value): void;
}

class Map implements MapInterface {
public function set(string $key, mixed $value): void {
// Store the key/value pair somehow
}
}

Let's assume the return type MapInterface::set() mixed instead,
where the intention is for set() to return the previous value, or
null if there was none. This change will go completely unnoticed by
Map::set(), because void is now just null, which is a subtype of
mixed. This is a bug that would previously have been caught,
notifying you that you're supposed to return something.

Similarly, the code function foo(): void { return null; } is now
proposed to be valid, and I assume the inverse for void/return; is
also true. In this example, we now update Map::set() to the new
return type.

class Map implements MapInterface {
public function set(string $key, mixed $value): mixed {
$oldValue = /* Fetch old value somehow */;
// Store the key/value pair somehow

if (!$this->observers) {

return; // This line was here before.
}

$this->observers->notify($key, $oldValue, $value);

return $oldValue;
}
}

Good examples are hard, but imagine Map::set() would allow notifying
a list of observers about changes to the map. Previously, the
return; would have prevented an erroneous call to notify() on
null. However, now it is missing the returning of $oldValue. This
is another bug that would previously have been caught. In fact, even a
missing trailing return $something; would not be caught anymore.

IMO, these checks are useful enough not to be removed.

Please let me know if I'm missing anything.

I must say the examples are not really convincing to me. :)
The compile time warning would only be suppressed for case where the return type of the function/method is exactly null or void,
the moment you have a union type or mixed you would still get the compile time error.
I realise that I didn't properly describe the behaviour of my PoC implementation in the RFC, apologies for that.

And a type system on its own is never going to be able to catch all implementation bugs,
even with dependant and effect types, you can write code that passes a type checker yet not do what is expected.
A type system should be logical, and the fact that the top type (mixed) is not a super-type of all types doesn't make any sense.
We specifically included null within mixed as having a proper top type is required, even if many people would have preferred it to exclude null and just use ?mixed if you wanted "everything".

As said to Anton, PHP does not have the concept/capability of "not returning a value" (unless you throw/exit)

Final small cheeky note, we don't warn/error in other cases where we detect dead code, we let the optimizer get rid of them, is this something we should warn about?

Best regards,

Gina P. Banyard

Hello internals,

This is the second RFC out of a set of type system related RFCs I
want to propose for PHP 8.5.

The objective is to fix a weird quirk of PHP's type system, where
void lives in its own type hierarchy.
This is visible mainly in that a lack of return type is not
isomorphic to a function that has a return type of mixed.

Let me know what you think about it.

RFC: https://wiki.php.net/rfc/void-as-null

Best regards,

Gina P. Banyard

I have to agree with other posters here that the distinction between
null and void is an useful one.

In particular I'd consider the null returned by void to be incidental
rather than intentional. I consider the return value of void functions
"some arbitrary value". It just happens to be null.
Like every function has to return something. But returning null is not
an intrinsic property of a void function. It's an extrinsic one. You
observe void functions to generally return null. But that null in
itself is meaningless.

So, my counter-proposal would be allowing covariance with void and
allowing everything, including non-nullable types as child type of
void functions.
I.e. effectively giving void and never the same semantics, except that
never also indicates that it never returns.

Additionally I'd be in favour of disallowing (e.g. E_WARNING)
consuming the return value of direct calls to void functions (with
the exception of standalone direct calls in short closures, because
consuming that value is intrinsic rather than necessarily
intentional). (Disallowing indirect calls would be detrimental for
usage as callback.)

Bob

Clarification: opposite semantics to never (which is the bottom type).
Void would be effectively the top type (only inferior to untyped).

So, it allows child classes to then return a meaningful value when the
interface was just "void" (= no significant return type). As an example,
when the interface says "set($val): void", the child class can specify
"set($val): mixed" and return the old stored value.

Basically, an interface can now say without further clarification "I
have no real return value" = "void", rather than having to say "mixed"
and then explaining "this is not really mixed, but whatever you want".

(I have seen interface method return values being "upgraded" from void
to mixed (or just untyped) in the past, just so that a specific child
class can now return a meaningful value.)

Bob