intersection types and null for defaults, properties and return types

Hi all, I want to bring your attention to a behavior that was mostly overlooked: 1. it is not possible to use an intersection type with an argument that defaults to null 2. it is not possible to use an intersection type with a nullable property (nor to make it default to null) 3. it is not possible to use an intersection type with a nullable return type Actually, 2. was possible until it was "closed" in https://github.com/php/php-src/pull/7254 I reported these behavior and you might find some discussion about it in https://bugs.php.net/81268 Looking at the past discussion on this list ( https://externals.io/message/113712) and at the rfc itself ( https://wiki.php.net/rfc/pure-intersection-types), this was mostly overlooked. That's why I'm posting this message. So that we can have that missing discussion here. To me, we are going to need (userland "we") these capabilities. It's quite surprising to be "forced" to return something, or "forced" to pass a value, when all other types in PHP allow "null". I know about the null pattern, but it is quite uncommon in PHP, because "null" works just great usually. I feel like we "just" need to agree on a syntax to make this possible. It was first suggested in the related PR to use "?A&B" (see https://github.com/php/php-src/pull/6799#issuecomment-804761117) This was rejected by the author with the reasoning that (?A)&B could mean (?A)&B or ?(A&B) or even (?A)|B. I personally don't think this ambiguity exists: (?A)|B is strictly the same as A&B, thus ?A&B cannot also mean A&B, and I don't get how one could take ?A&B for (?A)|B. Another argument is that ?A&B might collide with a future syntax. But I fail to see how. For sure we create examples of such collisions, but they all look constructed to me. Shouldn't we allow ?A&B ? Intersection types look unfinished to me without compat with nullables. Cheers, Nicolas