Re: intersection types and null for defaults, properties and return types
| From: | azjezz | Date: | Mon, 19 Jul 2021 09:21:49 +0000 |
| Subject: | Re: intersection types and null for defaults, properties and return types | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-115482@lists.php.net to get a copy of this message | ||
Hello,
I personally don't consider a bug, but an expected behavior.
when writing:
```
T $x = null
```
it is the same as writing:
```
T|null $x = null
```
or
```
?T $x = null
```
however, when
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc
T is an intersection between X and T (
X&Y ), X&Y $x = null becomes null|X&Y $x = null,
which is a combination between union and intersection types, however, as the RFC stats, currently
combination between union and intersection types is not support ( hence "pure" )..
for this to be allowed, PHP would need to support combining union and intersection types, preferable
using parenthesis ( X|(Y&Z) $x = null or (X&Y)|Z $x = null ).
Regards,
Saif.
������� Original Message �������
On Monday, July 19th, 2021 at 9:41 AM, Nicolas Grekas <nicolas.grekas@gmail.com> wrote:
> 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
>
> VÅù¼_Ùó
> °:´¤ñé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
Attachment: [application/pgp-signature] OpenPGP digital signature signature.asc