On Mon, 4 Oct 2021 at 04:33, Levi Morrison <levi.morri...@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....@gmail.com> wrote: > 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. > 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 <m...@newclarity.net> wrote: > Regarding the RFC's proposed disallowing of `?null`, is that really needed? > 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ătrănescu <dreal...@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() = '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. 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
