On Sat, Oct 2, 2021 at 6:07 PM G. P. B. <george.bany...@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
