Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116234
MIME-Version: 1.0
References: <CAFPFaM+M5gtCmGZrOZdH0zatS-472_xVodhw6EoU0z3mPxNyYw@mail.gmail.com>
In-Reply-To: <CAFPFaM+M5gtCmGZrOZdH0zatS-472_xVodhw6EoU0z3mPxNyYw@mail.gmail.com>
Date: Wed, 6 Oct 2021 01:58:14 +0300
Message-ID: <CAAwdEzCW27JP=c-BEOsf=Qd8QwisSWPhny95MmQr4Do2MZDJqw@mail.gmail.com>
To: "G. P. B." <george.banyard@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e15b6505cda2f7bc"
Subject: Re: [PHP-DEV] [RFC] Allow null as standalone type
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000e15b6505cda2f7bc
Content-Type: text/plain; charset="UTF-8"

On Sat, Oct 2, 2021 at 6:07 PM G. P. B. <george.banyard@gmail.com> wrote:

> Hello internals,
>
> I'm proposing a new RFC to make 'null' usable as a standalone type.
>
> RFC: https://wiki.php.net/rfc/null-standalone-type
> GitHub PR: https://github.com/php/php-src/pull/7546
>
> Best regards,
>
> George P. Banyard
>

Hey George, thank you for driving the effort forward.

This looks good to me and I think having null as a return type makes it a
bit more clear.
I think the difference between a function returning void vs null will be
clear enough.


But there is one more small elephant in the RFC that I believe should be
discussed.
null|false type will not be a nullable named type but it will be an union
between two named types.

It's not totally unexpected. All types that are combined with false are a
union type so far.

But also, related to null, it will be the first case that will be different.
So far, all types that are combined with null are not necessarily union but
their other type that has an allowsNull() that returns true.

One could argue that we can also have it as a ReflectionNamedType with
getName() = 'false' and  allowsNull() = true.

I feel that the preferred solution will push more towards the general
desire to represent the nullable types notations more and more like an
union.
I can see how what was initially proposed in
https://wiki.php.net/rfc/nullable_intersection_types for (X&Y)|null
might end up being UnionType(IntersectionType(NamedType(X), NamedType(Y)),
NamedType(null))
instead of the originally proposed  IntersectionType(NamedType(X),
NamedType(Y) with allowsNull() = true.

I mean, that's not necessarily a bad thing in my opinion. But maybe it's
good to discuss the future plans as well.
For any new nullable construct should we use a ReflectionUnionType with
ReflectionNamedType for null and not use the allowsNull method?
Should we have a plan to convert current nullable constructs to a
ReflectionUnionType and eventually drop the allowsNull method in PHP 9.0?

On the other hand, while we have the allowsNull method maybe we can keep
the pattern and not have a BC break and use it everywhere.
With an union, you need to iterate over all elements in the union and check
that one is a named reflection for null.
Is there something we cannot achieve if we do it like this?

I don't have a strong preference for either. But I think it would be good
to discuss it.


While writing this, I realize that the RFC should probably specify in the
Reflection section also the simple use case, null, not just the null|false
combination.
I assumed it would be a ReflectionNamedType for null but I think that it
should be clearly specified along with what the getName method will return.
Also, what will the allowsNull method return? If false, should the
recommended pattern for checking if null is allowed be
($reflectionType->allowsNull() || $reflectionType->getName() === 'null')
Or maybe the name should be 'NULL', to match the result of gettype(null)?
If not, maybe we can mention the difference to the gettype function.


Regards,
Alex

--000000000000e15b6505cda2f7bc--