On Tue, Oct 5, 2021 at 3:45 PM Nikita Popov <nikita....@gmail.com> wrote:
> On Tue, Oct 5, 2021 at 4:08 PM Côme Chilliet <c...@chilliet.eu> wrote:
>
> > Le lundi 4 octobre 2021, 10:09:12 CEST Nikita Popov a écrit :
> > > 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.
> >
> > 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 being
> 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
>
