Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116205
MIME-Version: 1.0
References: <CAFPFaM+M5gtCmGZrOZdH0zatS-472_xVodhw6EoU0z3mPxNyYw@mail.gmail.com>
 <CAAKU0umCQsdDNeasvDxZHTjGpHdKht=_uyzhbjJ96h+-ih_5PQ@mail.gmail.com>
In-Reply-To: <CAAKU0umCQsdDNeasvDxZHTjGpHdKht=_uyzhbjJ96h+-ih_5PQ@mail.gmail.com>
Date: Mon, 4 Oct 2021 10:09:12 +0200
Message-ID: <CAF+90c8d0+m6W0hajBSqGF6+nbzUrXQ5vghx4bO69qq5By53PA@mail.gmail.com>
To: Levi Morrison <levi.morrison@datadoghq.com>
Cc: "G. P. B." <george.banyard@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000922f5805cd826e36"
Subject: Re: [PHP-DEV] [RFC] Allow null as standalone type
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000922f5805cd826e36
Content-Type: text/plain; charset="UTF-8"

On Mon, Oct 4, 2021 at 5:33 AM Levi Morrison via internals <
internals@lists.php.net> wrote:

> On Sat, Oct 2, 2021 at 9:07 AM G. P. B. <george.banyard@gmail.com> wrote:
> >
> > Hello internals,
> >
> > I'm proposing a new RFC to make 'null' usable as a standalone type.
> >
> > RFC: https://wiki.php.net/rfc/null-standalone-type
> > GitHub PR: https://github.com/php/php-src/pull/7546
> >
> > Best regards,
> >
> > George P. Banyard
>
> I don't see the word `void` in the RFC. I think there ought to be
> something said about how naked `null` is different or not different
> than `void`.
>

Right. To quote the original union types RFC, this was the motivation for
the current limitation:

> The null type is only allowed as part of a union, and can not be used as
a standalone type. Allowing it as a standalone type would make both
function foo(): void and function foo(): null legal function signatures,
with similar but not identical semantics. This would negatively impact
teachability for an unclear benefit.

I'm not opposed to making null usable as a standalone type though. I think
the fact that a "void" function must use "return;" instead of "return
null;" and a "null" function conversely must use "return null;" instead of
"return;" will probably be sufficient disambiguation.

If we make this change, I would however suggest to also support "false" as
a standalone type. I think this change primarily has benefits from a
typesystem completeness perspective rather than a strong practical need.
From that angle, it would be nice if all types that are usable in a union
are also usable as standalone types, rather than shifting the special case
from null to false.

Regards,
Nikita

--000000000000922f5805cd826e36--