Re: intersection types and null for defaults, properties and return types

From: 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 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
« previous php.internals (#115482) next »