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 >
