Re: [RFC] Nullable intersection types

>> @Larry makes an argument to keep them: >> >>> Requiring parenthesis now leaves the option open in the future to make them optional >>> when doing full mixed types. >> >> >> I don’t understand why we should require something that is not needed simply because it >> would give us an option to remove it later… Could you elaborate why this is important? (Im >> probably missing something) > > The difference is if we make the decision to use the ?X&Y > syntax and we later realize it was a mistake then we are stuck with it. > > OTOH if we use the (X&Y)|null syntax and later realize it is okay to also allow > ?X&Y PHP could later be changed to allow it. > > The later is the choice that manages future risk better. I thought Larry was discussing X & Y | null vs (X & Y) | null. I’ve dropped ?X&Y because Derick had technical arguments against it. The way I see it, there is no benefit in requiring the parentheses in (X & Y) | null. I suggest we use X & Y | null. >>> Given both of these sets of assertions I would ask the RFC's author and proponents >>> what would be a worse outcome? >> >> I don’t see how this question is relevant. We are not seeking compromises at the moment. >> We are seeking the best technical solution to a technical issue. > > If you are not willing to compromise you will probably get nothing. > > It is relevant because I was trying to get you to ask yourself if you would be happier if you > get half of what you want rather than none of what you want. > > Because there is a very real possibility you will get none of what you want if the RFC requires > the syntax so many have objected to. > > BTW, I do not have a strong opinion either way, but since I see than many do have a strong > opinion I was trying to play arbitrator between two sets of people who each have very entrenched > opinions where their opinions are in conflict. If neither side will budge, nobody wins. That is a strange attitude. You are saying that you rather see a release with a know flaw than actually trying to find the best solution. The release will be in 4 months. There is a process to clearly find issues like this. There is plenty of time to review this RFC and release it in beta 2 and let people test it. This is not a last minute thing, the process is designed for this. >>> o, the entire discussion has claimed a "need" for nullable intersection types >>> but AFAIIK they have been presented in completely abstract terms; i.e. no one has presented any >>> real-world scenarios where they would actually use nullable intersection types. >> >> >> The “need” is covered by the discussion about PHP 7.0. See this post as an example: >> https://externals.io/message/115554#115563 >> <https://externals.io/message/115554#115563> > That message mentioned the need in abstract, but it did not provide any real-world examples. > It claims that there were real-world examples, but did not show any. > > That message was also not part of the RFC. The first paragraph under “Rational” mentioned this: https://wiki.php.net/rfc/nullable_intersection_types#rationale <https://wiki.php.net/rfc/nullable_intersection_types#rationale> In my world maintaining PHP libraries, it is obvious that 7.0 was missing this feature. As Benjamin mentioned, you could see that all libraries that migrated from 5.x just skipped 7.0 and went straight to support 7.1. I did the same for all my packages because of this reason. I made a misstake to assume that everybody had the same “world of maintaining PHP libraries” as I do. So the “real world examples” you are looking for is: If we don’t merge a version of this RFC in 8.1, PHP packages will not take leverage of the inspection types until PHP 8.2. The reason for a package to drop PHP 7 support is to be able to use the cool features in PHP 8. This will require a major release (something all maintainer should do sparsely). Why would I do a new major release if I cannot properly define my API (interfaces)? I rather wait to next PHP version where I can express my API and do my major release then. As the RFC states and Benjamin made extra clear, this is exactly what happened with PHP 7.0. > > Listen, I am trying to help make the RFC better to improve its chance of passing. If you > don't want that, then I will just demure. > Sorry if I sounded (or keep sounding negative). I appriciate you and everybody else participate in this discussion. We are all trying to make PHP better and we are all trying to move this RFC forward. // Tobias