Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116232
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> <CAF+90c8mi3kNNdH8bcpn5y4Net_3GkjTD=GLF77zbaACtW_KaQ@mail.gmail.com>
In-Reply-To: <CAF+90c8mi3kNNdH8bcpn5y4Net_3GkjTD=GLF77zbaACtW_KaQ@mail.gmail.com>
Date: Tue, 5 Oct 2021 18:56:55 +0100
Message-ID: <CA+p1Faafmxu=RBOk4a2YpcxkDM2=PQqoeoyY_ne7=BjCWXK6Vg@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: =?UTF-8?Q?C=C3=B4me_Chilliet?= <come@chilliet.eu>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000013d58805cd9ec23c"
Subject: Re: [PHP-DEV] [RFC] Allow null as standalone type
From: davidgebler@gmail.com (David Gebler)

--00000000000013d58805cd9ec23c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Oct 5, 2021 at 3:45 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

> On Tue, Oct 5, 2021 at 4:08 PM C=C3=B4me Chilliet <come@chilliet.eu> wrot=
e:
>
> > 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 "fals=
e"
> > 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.
> >
> > It feels weird/wrong to slowly add values in the type system like this,
> > rather than directly supporting static values as type hints.
> >
> > Why would function a(): null|false {} be legal but function b(): null|0
> > would not?
> >
> > This is inconsistent to me. And adding null, then false, then true for
> the
> > sake of completeness feels like avoiding to treat the static value as
> type
> > hint subject.
> >
>
> Both null and false are already part of the type system. They're not bein=
g
> added, neither by the RFC in question, nor by my quoted suggestion. This
> discussion is only about relaxing restrictions on standalone types.
>

I always thought false was part of the type system just to accommodate the
legacy of internal functions which can return a (non-boolean) value or
false. I mean, I've never written code that's type hinted something|false
as a return type, to me a function/method return should either be type
hinted bool or not. Even with union types, if I was writing something|bool
there might be conceivable occasions it's justified, but I'd at least be
asking myself if it could be a design smell in whatever I'm building. I
guess I'm saying I've always considered the fact you *can* do this with
false more a legacy of necessity than a feature which should be built on.
Null is distinctly a type as well as a value so I can see the justification
for the RFC; it seems harder to make that argument for false, beyond saying
"well in PHP, it just is"...but...is that a good thing?


>
> So to answer your question: "null|false" would be legal because
> "string|false" already is. "null|0" would be illegal because there is no
> such thing as a "0" type (in our current type system).


> Regards,
> Nikita
>

--00000000000013d58805cd9ec23c--