> On Tue, 5 Oct 2021 at 23:58, Alexandru Pătrănescu <[email protected]> > 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() = '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? > > > > 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. > > Thanks for sharing this. In this case, using a ReflectionUnionType sounds perfectly in line with the plans for the future.
Related to my mention about deprecation and dropping of allowsNull, I guess that is not really needed. I can see how we could add along with the current public function allowsNull(): bool a new function like public function allows(mixed $value): bool and keeping them both in the end could be fine. But this is a topic for some other RFC, not for this. > 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. > > Thank you for the correction. allowsNull() can be used on the ReflectionUnionType directly, of course. I guess I was trying to find a disadvantage for it but failed. > > The slightly amended RFC can be again found here: > https://wiki.php.net/rfc/null-standalone-type > > Best regards, > > George P. Banyard > Regards, Alex
