Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116226
MIME-Version: 1.0
References: <CAFPFaM+M5gtCmGZrOZdH0zatS-472_xVodhw6EoU0z3mPxNyYw@mail.gmail.com>
 <CAAKU0umCQsdDNeasvDxZHTjGpHdKht=_uyzhbjJ96h+-ih_5PQ@mail.gmail.com>
 <CAF+90c8d0+m6W0hajBSqGF6+nbzUrXQ5vghx4bO69qq5By53PA@mail.gmail.com> <4638866.snJnjoNyIA@tempete>
In-Reply-To: <4638866.snJnjoNyIA@tempete>
Reply-To: Levi Morrison <levi.morrison@datadoghq.com>
Date: Tue, 5 Oct 2021 08:34:15 -0600
Message-ID: <CAAKU0umtuEwyWQWKe+a9jt4+uapatDnWhN7VB72LTZ+XEt9C7g@mail.gmail.com>
To: =?UTF-8?Q?C=C3=B4me_Chilliet?= <come@chilliet.eu>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Allow null as standalone type
From: internals@lists.php.net ("Levi Morrison via internals")

On Tue, Oct 5, 2021 at 8:08 AM C=C3=B4me Chilliet <come@chilliet.eu> wrote:
>
> Le lundi 4 octobre 2021, 10:09:12 CEST Nikita Popov a =C3=A9crit :
> > 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 uni=
on
> > are also usable as standalone types, rather than shifting the special c=
ase
> > from null to false.
>
> It feels weird/wrong to slowly add values in the type system like this, r=
ather than directly supporting static values as type hints.
>
> Why would function a(): null|false {} be legal but function b(): null|0 w=
ould not?
>
> This is inconsistent to me. And adding null, then false, then true for th=
e sake of completeness feels like avoiding to treat the static value as typ=
e hint subject.
>
> C=C3=B4me
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Null is both a type and a value. It's odd that we don't support null
as a standalone type, because it's the only case I can think of where
we have a value without a type in the type system. You could possibly
argue the same about `resource`, but that's a legacy type we are
working on removing (and special thanks to everyone who has
participated).

Integers are not the same. If you want to support integer literals and
probably all forms of literals as types, I suggest that as a separate
RFC. I really don't think they are the same.