Re: [RFC] Nullable intersection types
| From: | Andreas Leathley | Date: | Tue, 27 Jul 2021 14:45:38 +0000 |
| Subject: | Re: [RFC] Nullable intersection types | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115592@lists.php.net to get a copy of this message | ||
On 23.07.21 11:58, Nicolas Grekas 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 Please have a look and let me know what you think.I would suggest to only offer a vote on (A&B)|null being allowed - not because I personally believe in that option, but because there seems to be a lot of tension around being forward-compatible and finding a solution that is as "safe" as possible. I fear if there are multiple syntax options, the rate of no-votes will just be higher, and the RFC will have no chance. From a userland POV I do not think it matters much if for now it is (A&B)|null or A&B|null - the point should be that nullability is possible and can be defined in code. If extra brackets seems to be more future-proof, then why not. Having one clear RFC voting option (with no secondary syntax voting option) also seems the most honest, as if somebody agrees that nullability would be useful but would only accept one syntax choice, that seems impossible to represent, necessitating a no vote on the whole RFC.