On Tue, Oct 5, 2021 at 8:08 AM 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.
>
> Côme
>
> --
> 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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
