> On Jul 24, 2021, at 12:42 AM, 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)
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. >> 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. >> 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. 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. -Mike > > —————— > > 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 >> <mailto:m...@newclarity.net>> wrote: >> >>> On Jul 23, 2021, at 5:58 AM, Nicolas Grekas <nicolas.gre...@gmail.com >>> <mailto: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 >>> <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 >
