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.
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
