I do not think this is strictly true. The issue that this RFC is running into is that combination types between intersections and unions was something that was avoided for the intersection types RFC. Not because the authors never thought of it, but because the RFC would have become very broad and encompassed many different discussions. But since the issue of adding combination types *only* for null is now being presented, it seems to me that a lot of people are taking the position that the syntax for it should match what the future implementation of combination types is to avoid confusion. I don't think that's an unreasonable position to take, and the difficulty of that discussion perhaps illustrates why this wasn't included in the original RFC.
> We are not seeking compromises at the moment. We are seeking the best technical solution to a technical issue. But this presumes that the ONLY technical issue at hand is the ability to have nullable intersections. Intersections are only available for class types, you can't use intersections with scalars. The *best* technical solution since there are no scalars is for people to use classes which have a null state internally, or at least I could argue that's the case. (In fact I *did* argue that's the case in a previous thread.) I'm not even convinced that this is a technical issue at this point, so the idea that there's no need for compromise is rather strange to me. If the goal is to support nothing but nullable intersections, there's an entire programming pattern[1] to solve that concern. But as nulls have always just "worked" for most PHP developers, I *can* see the argument for it despite the fact that I think it promotes bad program design. I know that I will use intersection types with the null object pattern in my own libraries even if nullable intersection types are added. So given that it's a special case of combination types, it makes sense that people are at least *discussing* what combination types should look like longer term. > 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… The point (I think) that Larry was making is that the parentheses can always be made optional in the future, but if this is delivered without parentheses now, it will be very, very hard to make parenthesis mandatory later (BC break) if there is a reason to do so. What would that reason be? I'm not sure, because a full implementation and RFC for combination types hasn't been proposed yet So requiring parentheses places the fewest restrictions on the anticipated future RFC for combination types and allows the author to find the best technical solution to *that* issue. --- [1]: https://en.wikipedia.org/wiki/Null_object_pattern On Fri, Jul 23, 2021 at 9:43 PM Tobias Nyholm <tobias.nyh...@gmail.com> wrote: > > It seems this RFC is actually trying to accomplish two(2) things: > > > > 1. Add typehints for nullable intersection types to PHP. > > 2. Get PHP to support a preferred syntax for type-hinting nullable > intersection types. > > Yes of course. You cannot really do #1 without #2. > > I agree with Nicolas that `?X&Y` makes more sense. You add ? before the > type. If the type is scalar, a class or an intersection type should not > matter. But I hear some technical arguments from Derick so I won’t argue > against that. > > Im fine with the syntax: `X & Y | null` > I don’t think parentheses should be required. From a mathematical > perspective you want to add parentheses when you want to override the > operation order. If you remove the parentheses and the expression has the > same order of operations, then the parentheses is clearly not needed. > > @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) > > > 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. > > > Also, 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> > > —————— > > When reading my message above could make it sound like I am pessimistic. > That is not true. I am excited about this change and I am happy PHP has a > long feature freeze so issues like this can show up before the release. > > Regards, > Tobias > > > > On 23 Jul 2021, at 20:53, Mike Schinkel <m...@newclarity.net> wrote: > > > >> On Jul 23, 2021, at 5:58 AM, Nicolas Grekas <nicolas.gre...@gmail.com> > wrote: > >> > >> Hi everyone, > >> > >> as proposed by Nikita and Joe, I'm submitting this late RFC for your > >> consideration for inclusion in PHP 8.1. Intersection types as currently > >> accepted are not nullable. This RFC proposes to make them so. > >> > >> I wrote everything down about the reasons why here: > >> https://wiki.php.net/rfc/nullable_intersection_types > >> > >> Please have a look and let me know what you think. > >> > >> Have a nice read, > >> > >> Nicolas > > > > It seems this RFC is actually trying to accomplish two(2) things: > > > > 1. Add typehints for nullable intersection types to PHP. > > 2. Get PHP to support a preferred syntax for type-hinting nullable > intersection types. > > > > Further: > > > > A. There seems to be consensus on the value of #1. > > B. There seems to be consensus on using a syntax with parentheses for > #1. > > C. There is a lot of pushback on #2. > > D. The desired syntax in #2 would reduce future flexibility, as Larry > Garfield commented. > > > > Given both of these sets of assertions I would ask the RFC's author and > proponents what would be a worse outcome? > > > > X. Getting typehints for nullable intersection types added to PHP, but > not the desired syntax? > > Y. Not getting typehints for nullable intersection types added to PHP? > > > > When answering please consider that #X is the outcome that would not > preclude possibly getting #2 at a future date. > > > > --------- > > > > Also, 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. > > > > It might be helpful — or at least it would be for me — if the RFC could > add two or three real-world example use-cases where the author and > proponents would actually like to use nullable intersection types in their > future PHP code. > > > > #jmtcw > > > > -Mike > >
