Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116236
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 17:09:00 +0100
Message-ID: <CAFPFaMJWRLyoDuCT-Q7459UFcbDM1E5SrQ=G2bvyH7RkhAPRDw@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e9b66305cdb15dc6"
Subject: Re: [PHP-DEV] [RFC] Allow null as standalone type
From: george.banyard@gmail.com ("G. P. B.")

--000000000000e9b66305cdb15dc6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Mon, 4 Oct 2021 at 04:33, Levi Morrison <levi.morrison@datadoghq.com>
wrote:

> I don't see the word `void` in the RFC. I think there ought to be
> something said about how naked `null` is different or not different
> than `void`.


Added a section which attempts to explain the difference between both.

On Mon, 4 Oct 2021 at 09:09, Nikita Popov <nikita.ppv@gmail.com> wrote:

> If we make this change, I would however suggest to also support "false" a=
s
> 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 cas=
e
> from null to false.
>

I'm not against adding false as a standalone type, but I haven't amended
the RFC just yet as it would require some major rewording and I want to be
sure most people are on board with this change.


On Tue, 5 Oct 2021 at 17:55, Mike Schinkel <mike@newclarity.net> wrote:

> Regarding the RFC's proposed disallowing of `?null`, is that really neede=
d?
>

Yes, this is in line with PHP's current type redundancy checks.
One cannot write ?mixed, nor int|int, nor iterable|Traversable, as the
types are redundant.

On Tue, 5 Oct 2021 at 23:58, Alexandru P=C4=83tr=C4=83nescu <drealecs@gmail=
.com>
wrote:

> 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() =3D 'false' and  allowsNull() =3D 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() =3D 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?
>

From my understanding and the comments in the source code, and Nikita might
want to clarify, the only reason why it still returns a NamedType is for
BC, to allow tools that worked on PHP 7 to still run on PHP 8 even if
nothing else changed.
As Reflection based tooling gets updated to deal with the additions to the
type system I expect that we will change the representation of ?T to a
ReflectionUnionType, as to maintain the old behaviour we do things that
could be removed and simplified by using the more standard representation.

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?
>

This is incorrect: https://3v4l.org/P9U4u
There is no intention to change this behaviour in this RFC.


The slightly amended RFC can be again found here:
https://wiki.php.net/rfc/null-standalone-type

Best regards,

George P. Banyard

--000000000000e9b66305cdb15dc6--