Re: intersection types and null for defaults, properties and return types

Replying to multiple things: On Mon, Jul 19, 2021 at 8:16 PM G. P. B. <george.banyard@gmail.com> wrote: > > And I find it frankly insulting that in the four month this RFC has been > published for discussion, with multiple push backs for voting due to bugs > and me wanting that people know what implementation is - for the most part > - going to land in php-src, this specific point has not been raised. > I'm sorry if you felt it like that (even if maybe not from me personally), as I had the impression that it *has* been raised, several times: - https://externals.io/message/113712#113730 : "Does this miss an opportunity, though? It's useful to be able to write A&B|null." - https://github.com/php/php-src/pull/6799#issuecomment-804761117 : "Is there any reason to not allow ?A&B type?" - https://github.com/php/php-src/pull/6799#issuecomment-805175050 : "However, if I'm not mistaken, you would create the only type that is not nullable. That feels like an unnecessary edge-case. Would it be very difficult to at least allow the union of an intersect type with null?" Even though you replied to each of them (explaining the why, so I didn't add an extra voice then*), that does look like this specific point was actually raised in early discussion? *But I can add my thank you for implementing this feature in the first place! =) On Tue, Jul 20, 2021 at 1:07 PM Nikita Popov <nikita.ppv@gmail.com> wrote: > > I don't think there's been any malicious intent here -- it was obvious to > you and I that not allowing unions implies not allowing nullability, but I > can see how people less familiar with our type system implementation would > not make that connection. After all, we do provide the separate ?T syntax, > even if it is an internal alias for T|null. > > It's an unfortunate fact of the RFC process that concerns are sometimes > only raised when voting starts and people start looking at the > implementation -- or in this case, when they test the implementation after > it has landed... > Agreed to both points. On Tue, Jul 20, 2021 at 7:40 PM Jordan LeDoux <jordan.ledoux@gmail.com> wrote: > > For example, in my own projects if I had the need for such a thing, I > would instead use: X&Y&Optional. This would enable me to provide > arbitrarily detailed information about the conditions of the optional > nature of the data and an implementation of it that was aware of the nature > of my program. That can't be easily achieved with nulls. > Nicolas said: "I know about the null pattern, but it is quite uncommon in PHP, because "null" works just great usually." (and I would add that it probably suffers from the lack of generics and/or tagged unions). In retrospect, do you think you would argue against https://wiki.php.net/rfc/nullsafe_operator ? and even https://wiki.php.net/rfc/nullable_types ? On Tue, Jul 20, 2021 at 9:19 PM Deleu <deleugyn@gmail.com> wrote: > > I don't know if anyone has offered this before, but if making an exception > for nullable Intersection is on the table, what about putting the null sign > at the end? > > X&Y&Z? > > It doesn't seem ambiguous because PHP defines ?X as nullable X. It doesn't > seem obvious what the ? is doing at the end but at least it doesn't seem > ambiguous. > >> IIRC one reason the prefix syntax was chosen (for PHP) instead of the postfix one (from other languages) is to prevent a potential conflict with hypothetical future generics using a "X<Y>" syntax (because "X<Y?>" would then have been interpreted as a PHP closing tag). On Wed, Jul 21, 2021 at 9:05 AM Nicolas Grekas <nicolas.grekas@gmail.com> wrote: > > Thanks Nikita, Joe and the others for opening the possibility of a late > RFC. I'm going to write one down asap! > Thanks, looking forward to the RFC.