Re: [RFC] Nullable intersection types

Hi internals I wanted to apologise for the poor wording I used in my previous mail when I said "oversight". What I meant to say is what Nicolas described in his followup mail: feature freeze as a time to polish implementations. I personally consider nullability to be more of an implementation polishment, but I realise the syntax question makes it a more difficult question. While my personal experience with 7.0 and the lack of nullability was really annoying, I'm sure we'll all survive if 8.1 doesn't include nullability support. I just wanted to clarify those points, sorry if my previous mail caused any inconvenience. Kind regards Brent > On 28 Jul 2021, at 09:29, Nicolas Grekas <nicolas.grekas@gmail.com> wrote: > > 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. >> > > Hi everyone, > > Thank you for the contributions made to the discussion so far. I'm mostly > AFK these days, hiking in Greece. That gives me time to think about > comments made here, among other things :) > > Given the strong opposition from some, I considered withdrawing the RFC. > But since I also see some nice support, I decided not to: even if the > proposal is rejected, everyone should have the right to express their > opinion, and the vote is the only option to not let only the most vocal or > the most eloquent decide for the others. > > For the same reason, I'm not going to restrict the voting options to > (X&Y)|null as some requested. I will change my mind if we spot that some > syntax would put us in a corner. But so far and while I tried to be as > careful as possible, all syntax proposals are future-proof to me. I get > that some have strong coding style preferences, but that doesn't make a > technical argument. It's true that deciding to allow no brackets won't > allow us to force them later on. By why would we *force* them in the first > place? While you may not like relying on it, operator precedence is a nice > thing. I would hate having to put brackets around every single expression > in PHP. For types, there are only two to three operators: we don't have to > remember the full precedence table. And only one precedence makes sense > anyway, so it's easy to remember. I'm not advocating that we should forbid > brackets. Actually I'm going to vote for allowing both with and without > them, because I don't want to force my preferred coding style to others. > > I do have a preference for using the ? operator. It is compact > and > nullability *is* a flag. I'm reviewing code that use foo|null|bar, other > that use foo|bar|null. That makes reading the code harder. About its > precedence, I explained why I didn't need to be creative in the RFC: > ? > has to be the lowest precedence type-operator. Any other options would make > no sense from a logical pov. It would be so sweet and consistent to be able > to use it all the time to express the nullability flag. I would mind if we > allowed both ? and |null btw. > > Intersection types are a really useful addition to the language, please > don't suggest I framed it otherwise. I just thought that they would be a > lot less useful if they were not nullable, especially considering that they > could be part of public signatures that have to be maintained with BC in > mind. I'm happy that some agree with this and share their experience about > it. > > Nullability is a special beast in PHP. We have a range of operators > dedicated to it. That's also why I think it deserves special care, and why > I think it's important to have this discussion before 8.1 is out. To me, > the feature freeze is also useful for this: polishing features that are > about to be released. I don't see us rushing here. > > Let's do a careful and rational analysis of the proposal and vote on the > very asked question. We do have enough time. > > TL;DR: I'm carefully looking for blockers and I'm calling for more examples > if you spotted one! > > Cheers, > Nicolas > >>