Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115540
MIME-Version: 1.0
References: <CAOWwgpm+PPhW6A5=Oi1tpdkQh9COGw5dQLE+Ek1p0BZ6T-xQsA@mail.gmail.com>
 <CAC5V6ggeLQYygZq13-Ux0VoSDiMUhAPR3Wr9AoT_oDoqu9yxgw@mail.gmail.com>
 <CAOWwgp=UhvGD2CjspXVSmDMHL6uf12sb_yS2JDUoEgON5boNbA@mail.gmail.com>
 <CA+kxMuR0B3_J1EdEpDDSq3JeNuL_Jv_tUZZywATY32itzegEdg@mail.gmail.com>
 <CAC5V6ggSNzvzQYbn+Wi4TT0+pqWx4n3Z2vY+pXnnD6Hzi7ma9w@mail.gmail.com>
 <CAFPFaMKGRq79G6pK8G34bgij4dqiwN_Ja8kn07RabjL+8wuSNA@mail.gmail.com>
 <CAF+90c-dnOm2vj2YSFqqC-e_w5rny09D+emE3paHRidrZ=Y7Jw@mail.gmail.com>
 <CAOwTYAv-pWDMmUD7OK3cc0zvD7a=5Z9SkiteSxU89MUm1kqShA@mail.gmail.com> <CAOWwgpnN-+VFqvMQ3QJ=1accyDnzf22vsxdtGb9OLQ8ogs8W+A@mail.gmail.com>
In-Reply-To: <CAOWwgpnN-+VFqvMQ3QJ=1accyDnzf22vsxdtGb9OLQ8ogs8W+A@mail.gmail.com>
Date: Wed, 21 Jul 2021 10:49:19 +0200
Message-ID: <CAC5V6gg1W128rE2_64ad30PntOg16pDMR=HMxOphupGmhdKKag@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000a792c805c79e3f14"
Subject: Re: [PHP-DEV] intersection types and null for defaults, properties
 and return types
From: guilliam.xavier@gmail.com (Guilliam Xavier)

--000000000000a792c805c79e3f14
Content-Type: text/plain; charset="UTF-8"

Replying to multiple things:

On Mon, Jul 19, 2021 at 8:16 PM G. P. B. <george.banyard@gmail.com> wrote:

>
> And I find it frankly insulting that in the four month this RFC has been
> published for discussion, with multiple push backs for voting due to bugs
> and me wanting that people know what implementation is - for the most part
> - going to land in php-src, this specific point has not been raised.
>

I'm sorry if you felt it like that (even if maybe not from me personally),
as I had the impression that it *has* been raised, several times:

  - https://externals.io/message/113712#113730 : "Does this miss an
opportunity, though? It's useful to be able to write A&B|null."
  - https://github.com/php/php-src/pull/6799#issuecomment-804761117 : "Is
there any reason to not allow ?A&B type?"
  - https://github.com/php/php-src/pull/6799#issuecomment-805175050 :
"However, if I'm not mistaken, you would create the only type that is not
nullable. That feels like an unnecessary edge-case. Would it be very
difficult to at least allow the union of an intersect type with null?"

Even though you replied to each of them (explaining the why, so I didn't
add an extra voice then*), that does look like this specific point was
actually raised in early discussion?

*But I can add my thank you for implementing this feature in the first
place! =)

On Tue, Jul 20, 2021 at 1:07 PM Nikita Popov <nikita.ppv@gmail.com> wrote:

>
> I don't think there's been any malicious intent here -- it was obvious to
> you and I that not allowing unions implies not allowing nullability, but I
> can see how people less familiar with our type system implementation would
> not make that connection. After all, we do provide the separate ?T syntax,
> even if it is an internal alias for T|null.
>
> It's an unfortunate fact of the RFC process that concerns are sometimes
> only raised when voting starts and people start looking at the
> implementation -- or in this case, when they test the implementation after
> it has landed...
>

Agreed to both points.

On Tue, Jul 20, 2021 at 7:40 PM Jordan LeDoux <jordan.ledoux@gmail.com>
wrote:

>
> For example, in my own projects if I had the need for such a thing, I
> would instead use: X&Y&Optional. This would enable me to provide
> arbitrarily detailed information about the conditions of the optional
> nature of the data and an implementation of it that was aware of the nature
> of my program. That can't be easily achieved with nulls.
>

Nicolas said: "I know about the null pattern, but it is quite uncommon in
PHP, because "null" works just great usually."
(and I would add that it probably suffers from the lack of generics and/or
tagged unions).

In retrospect, do you think you would argue against
https://wiki.php.net/rfc/nullsafe_operator ? and even
https://wiki.php.net/rfc/nullable_types ?

On Tue, Jul 20, 2021 at 9:19 PM Deleu <deleugyn@gmail.com> wrote:

>
> I don't know if anyone has offered this before, but if making an exception
> for nullable Intersection is on the table, what about putting the null sign
> at the end?
>
> X&Y&Z?
>
> It doesn't seem ambiguous because PHP defines ?X as nullable X. It doesn't
> seem obvious what the ? is doing at the end but at least it doesn't seem
> ambiguous.
>
>>
IIRC one reason the prefix syntax was chosen (for PHP) instead of the
postfix one (from other languages) is to prevent a potential conflict with
hypothetical future generics using a "X<Y>" syntax (because "X<Y?>" would
then have been interpreted as a PHP closing tag).

On Wed, Jul 21, 2021 at 9:05 AM Nicolas Grekas <nicolas.grekas@gmail.com>
wrote:

>
> Thanks Nikita, Joe and the others for opening the possibility of a late
> RFC. I'm going to write one down asap!
>

Thanks, looking forward to the RFC.

--000000000000a792c805c79e3f14--