[PHP-DEV] [RFC] Transform void into an alias for null

Mailing Lists php.internals
21

On 4.6.2025 16:54:05, Bob Weinand wrote:

On 2.6.2025 18:27:51, Gina P. Banyard wrote:

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: PHP: 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

22

On Wed, Jun 4, 2025 at 1:35 PM Bob Weinand <bobwei9@hotmail.com> wrote:

On 4.6.2025 16:54:05, Bob Weinand wrote:

On 2.6.2025 18:27:51, Gina P. Banyard wrote:

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

MediaWiki’s hook system (https://www.mediawiki.org/wiki/Manual:Hooks) has two different kinds of hooks

  • those that can be aborted, for one hook handler to say that no other hook handlers should run
  • those that cannot be aborted

MediaWiki uses void return types to help enforce this system, where hooks that cannot be aborted must have void returns. See https://www.mediawiki.org/wiki/Manual:Hooks#Hook_handler_return_values. Making it so that any interface function with a void return can be implemented by a function returning anything would seem to be a huge B/C break. If you want to use the top type, why not just use mixed?

-Daniel

23

On 4.6.2025 22:39:28, Daniel Scherzer wrote:

On Wed, Jun 4, 2025 at 1:35 PM Bob Weinand <bobwei9@hotmail.com> wrote:

    On 4.6.2025 16:54:05, Bob Weinand wrote:
    > On 2.6.2025 18:27:51, Gina P. Banyard wrote:
    >> 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: PHP: 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

MediaWiki's hook system (Manual:Hooks - MediaWiki) has two different kinds of hooks
- those that can be aborted, for one hook handler to say that no other hook handlers should run
- those that cannot be aborted

MediaWiki uses `void` return types to help enforce this system, where hooks that cannot be aborted must have void returns. See Manual:Hooks - MediaWiki. Making it so that any interface function with a void return can be implemented by a function returning anything would seem to be a huge B/C break. If you want to use the top type, why not just use `mixed`?

-Daniel

Hey Daniel,

where's the BC break? Nothing which worked today will stop working (except you won't get exceptions in some cases). That's not a BC break. The only thing which stops working is if it's intentionally used as a guard.

However, in the case of MediaWiki they do actually _care_ about the return type (and the caller of these hooks will actually check for null/true/false). So it should be annotated ": null". And not ": void". Explicit intentions are important.
They probably still use ": void" as to be compatible with PHP 8.1 and older. ": null" is only supported starting PHP 8.2. I'd assume as they upgrade their required PHP version (8.1 currently) they'll shift to ": null".

So, yeah, the guard will lose its guarding functionality (but we don't consider that a BC break).

Regarding why not mixed? Because the intention with mixed is that the value is something meaningful. With void it's meaningless. There's a semantic distinction (and it forbids returning). And, as proposed, you could forbid direct calls of void functions giving runtime / static analysis hints. With void being covariant with respect to child functions now.

Bob

24

On Wed, Jun 4, 2025 at 4:49 PM Bob Weinand <bobwei9@hotmail.com> wrote:

On 4.6.2025 22:39:28, Daniel Scherzer wrote:

On Wed, Jun 4, 2025 at 1:35 PM Bob Weinand <bobwei9@hotmail.com> wrote:

On 4.6.2025 16:54:05, Bob Weinand wrote:

On 2.6.2025 18:27:51, Gina P. Banyard wrote:

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

MediaWiki’s hook system (https://www.mediawiki.org/wiki/Manual:Hooks) has two different kinds of hooks

  • those that can be aborted, for one hook handler to say that no other hook handlers should run
  • those that cannot be aborted

MediaWiki uses void return types to help enforce this system, where hooks that cannot be aborted must have void returns. See https://www.mediawiki.org/wiki/Manual:Hooks#Hook_handler_return_values. Making it so that any interface function with a void return can be implemented by a function returning anything would seem to be a huge B/C break. If you want to use the top type, why not just use mixed?

-Daniel

Hey Daniel,

where’s the BC break? Nothing which worked today will stop working (except you won’t get exceptions in some cases). That’s not a BC break. The only thing which stops working is if it’s intentionally used as a guard.

That (intentionally using void returns as a guard) is exactly what MediaWiki does. MediaWiki has an interface for each hook, that requires that hooks that cannot abort (return false) must return void; https://www.mediawiki.org/wiki/Manual:Hooks#Handling_hooks_in_MediaWiki_1.35_and_later. PHP is used to help enforce this.

However, in the case of MediaWiki they do actually care about the return type (and the caller of these hooks will actually check for null/true/false). So it should be annotated “: null”. And not “: void”. Explicit intentions are important.
They probably still use “: void” as to be compatible with PHP 8.1 and older. “: null” is only supported starting PHP 8.2. I’d assume as they upgrade their required PHP version (8.1 currently) they’ll shift to “: null”.

So, yeah, the guard will lose its guarding functionality (but we don’t consider that a BC break).

Why is this not considered a BC break? You can consider it a small break, but I think it should be noted in the BC section of the RFC.

Regarding why not mixed? Because the intention with mixed is that the value is something meaningful. With void it’s meaningless. There’s a semantic distinction (and it forbids returning). And, as proposed, you could forbid direct calls of void functions giving runtime / static analysis hints. With void being covariant with respect to child functions now.

Bob

If void is a top type indicating a return is meaningless, then callers would have no reason to examine the returned value, and then when subclasses do try to add meaning it might be missed. Am I missing something? How would void be different from “the base implementation happens to always return null, but subclasses can return other things, and the result can be meaningful”?

-Daniel

25

On Mon, Jun 2, 2025, at 18:27, Gina P. Banyard wrote:

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

Hi Gina,

This RFC feels inverted to me. Instead of making null equivalent to void, why not make using a void return an error (eventually) instead of it returning null?

— Rob

26

Bob

···

On 5.6.2025 02:59:56, Daniel Scherzer wrote:

On Wed, Jun 4, 2025 at 4:49 PM Bob Weinand <bobwei9@hotmail.com> wrote:

Hey Daniel,

where’s the BC break? Nothing which worked today will stop working (except you won’t get exceptions in some cases). That’s not a BC break. The only thing which stops working is if it’s intentionally used as a guard.

That (intentionally using void returns as a guard) is exactly what MediaWiki does. MediaWiki has an interface for each hook, that requires that hooks that cannot abort (return false) must return void; https://www.mediawiki.org/wiki/Manual:Hooks#Handling_hooks_in_MediaWiki_1.35_and_later. PHP is used to help enforce this.

However, in the case of MediaWiki they do actually care about the return type (and the caller of these hooks will actually check for null/true/false). So it should be annotated “: null”. And not “: void”. Explicit intentions are important.
They probably still use “: void” as to be compatible with PHP 8.1 and older. “: null” is only supported starting PHP 8.2. I’d assume as they upgrade their required PHP version (8.1 currently) they’ll shift to “: null”.

So, yeah, the guard will lose its guarding functionality (but we don’t consider that a BC break).

Why is this not considered a BC break? You can consider it a small break, but I think it should be noted in the BC section of the RFC.

It’s a small break in the sense of workflow, but compatibility breaks are concerned with the behaviours of non-erroneous functionality. (Code with worked yesterday works today. And not code which did not work yesterday works today).

But sure, the RFC may indicate it.

Regarding why not mixed? Because the intention with mixed is that the value is something meaningful. With void it’s meaningless. There’s a semantic distinction (and it forbids returning). And, as proposed, you could forbid direct calls of void functions giving runtime / static analysis hints. With void being covariant with respect to child functions now.

Bob

If void is a top type indicating a return is meaningless, then callers would have no reason to examine the returned value, and then when subclasses do try to add meaning it might be missed. Am I missing something? How would void be different from “the base implementation happens to always return null, but subclasses can return other things, and the result can be meaningful”?

-Daniel

What LSP builds upon is “if I code against this interface, my expectations will always be fulfilled”. If I code against the interface returning void, I do not care about the actual returned value and such my expectations are always fulfilled.

If I code against some subclass (or any of its children) which has a meaningful return type specified, and I’m aware of that return type, I may for sure use the return value. Nothing requires me to actually use the return value. It’s similar to optional parameters “When subclasses do try to add optional parameters, they might be missed”. That line of argumentation is a bit absurd :slight_smile: