> > 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. > > From the RFC: «Taking all these elements into account, the preference > of... and thus to use the "?X&Y" syntax». > > I think this would be a mistake. You touch upon operator precedence, and > needing to know whether | or & is higher, and inventing a new precedence > for ?. > > I would strongly advocate for not getting into the realm with any > operator precendence, but instead *require* parenthesis for any > combination. This gives the code reader and writer an immediate clue > about what the code does. Most coding standards also recommend this for > expressions in "if" statements and the like. > > I do however agree with Sara's «over-delivering syntax that hasn't been > entirely thought through» point. It will take a lot longer to come up > with a proposal to combine intersection and union types. >
That's another reason why I prefer going with "?X&Y". The situation we have here is very close to what we had back in 2016 when nullable types were introduced: we figured out that nullability was very much needed now, so we went with a syntax that would not overlap with a possible future RFC for unions. IMHO, going with (X&Y)|null is forcing a future we know little about. > That in combination that you're proposing this RFC after feature freeze, > while you've had four months to make this arguments as part of the "Pure > Intersection Types" RFC, I am currently not going to support this RFC > for inclusion into PHP 8.1. I wish I could have spotted that this discussion was needed earlier. Still, this is important for 8.1 (IMHO). >From the RFC: > For userland, if this nullable capability were added to a later version of PHP, making a parameter nullable later would cause a BC break (or force a major version bump when using semver.) Also this: > When PHP 7.0 introduced scalar types, it was obvious that the special null type was missing as a way to declare that null was a possible return value. PHP 7.1 added the “?foo” syntax to declare their nullability. This lesson from history tells us that the nullable type is special and very much needed in PHP. Nicolas
