Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115567
User-Agent: Cyrus-JMAP/3.5.0-alpha0-540-g21c5be8f1e-fm-20210722.001-g21c5be8f
Mime-Version: 1.0
Message-ID: <ff35c567-91f6-44fe-9708-3d49dd495d00@www.fastmail.com>
In-Reply-To: <77b313e3-e820-c50e-f921-40de5f41853f@processus.org>
References: 
 <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <BN7PR05MB4033B26F14CF1726EFFE810ADEE59@BN7PR05MB4033.namprd05.prod.outlook.com>
 <CAAKU0u=aznvHDBeQoPJoMUhHtDjDzKkMDxdcvPTNC7WT7Yb2AQ@mail.gmail.com>
 <77b313e3-e820-c50e-f921-40de5f41853f@processus.org>
Date: Fri, 23 Jul 2021 11:25:40 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: larry@garfieldtech.com ("Larry Garfield")

On Fri, Jul 23, 2021, at 11:06 AM, Pierre wrote:
> Le 23/07/2021 =C3=A0 17:56, Levi Morrison via internals a =C3=A9crit=C2=
=A0:
> >> As you note in the RFC, PHP already defines `|` as having a lower
> >> precedence than `&`, so `X & Y | null` can only be interpreted as
> >> `(X & Y) | null`. This is consistent with other languages such as
> >> TypeScript, where `A & B | C & D` is parsed as `(A & B) | (C & D)`.=

> >> [2]
> >>
> >> Since precedence is already defined for this syntax consistently wi=
th
> >> other languages, I don't think it's necessary to require parenthese=
s
> >> if we use the `A & B | null` syntax.
> > I want to acknowledge and reject this. Few people keep the bitwise
> > precedence information in their head. It's not worth it -- just
> > require parenthesis.
> >
> I don't want to reject this, this is actually a very good point, do no=
t=20
> reinvent a syntax that works somewhere else. And in the end, I do find=
=20
> this readable. (I prey that people will use space in they types=20
> definitions to make it even more readable, but style is not a topic fo=
r=20
> this RFC.)
>=20
> Accumulating union and sum types is probably not something I'd do ever=
y=20
> day, so in the end, I'll probably always go and read the documentation=
=20
> each and every time. But for people that do, they'll get used to it fa=
st=20
> enough I think.
>=20
> This behavior seems fine, at least I think it's fine, as long as the=20=

> documentation is clear.

Requiring parenthesis now leaves the option open in the future to make t=
hem optional when doing full mixed types.

Making them optional now requires that they be optional in the future wh=
en doing full mixed types.

I vaguely recall there being some potential issue with making them optio=
nal for full mixed intersection/union types, but not the details.  Eithe=
r way, it's a not-small decision to make, and may have complicated impli=
cations for future work.  It shouldn't be made on "eh, seems nicer" grou=
nds in a post-freeze last minute RFC.

Making it required now is the safer option, as it allows more flexibilit=
y in the future once someone tries to implement full union/intersection =
mixing.  Making it optional later may still happen, I don't know, but it=
 doesn't box us in to requiring it later.

--Larry Garfield