Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115591
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\))
In-Reply-To: <CAESVnVrCpYCB9VLFvAFbM4gzdBxHcmJQt75cqFcT0wHowMjXYw@mail.gmail.com>
Date: Tue, 27 Jul 2021 15:32:02 +0200
Cc: Nicolas Grekas <nicolas.grekas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <F039E1EA-572D-460A-93B5-CBEAA47780FF@stitcher.io>
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <CAESVnVrCpYCB9VLFvAFbM4gzdBxHcmJQt75cqFcT0wHowMjXYw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Nullable intersection types
From: brendt@stitcher.io (Brent Roose)

Hi all

=46rom a userland developer point of view:

- PHP 7.0 types were a pain because of non-nullable types, the feature =
only became really useful as of PHP 7.1
- I share many people's opinion that this falls in the category of =
oversight
- I think (A&B)|null is the only sensible way to go

Sidenote: weren't there any prior cases where an RFC was accepted only =
to have found out an oversight which resulted in that RFC to be =
postponed to the next release?

Kind regards
Brent

> On 26 Jul 2021, at 16:14, Sara Golemon <pollita@php.net> wrote:
>=20
> On Fri, Jul 23, 2021 at 4:58 AM Nicolas Grekas =
<nicolas.grekas@gmail.com>
> wrote:
>=20
>> https://wiki.php.net/rfc/nullable_intersection_types
>>=20
>>=20
> I've commented on the PR and in R11 a bit already, but I'd like to =
state my
> position here for the record.  I do see the value in having =
nullability,
> but I can't disagree enough with the `?X&Y` syntax no matter how
> technically right the argument about operator precedence is.  Even =
ignoring
> that literally nobody carries around a complete operator precedence =
table
> in their head, we simply can't predict how making this decision now =
will
> impact future plans for combined intersection/union types.  The same
> argument honestly goes for every other syntax proposed, including
> `(X&Y)|null` which is also prone to making things worse.
>=20
> Nullable intersection types *IS* an implementation of combined
> intersection/union types, even if a narrow one. Those have not been =
planned
> out or approved, and they're too broad to sneak in post feature =
freeze.
> Period. Let's take the coming months to flesh out the edge cases on
> combined types.  Let's maybe even look into type aliasing, which may =
have
> the side effect of making combined types more readable (or maybe less, =
who
> knows!).
>=20
> Most importantly, let's accept the fact that PHP's release cycle is =
only 12
> months and we had pandemics that lasted longer than that.  Next year =
is
> right around the corner.
>=20
> TL;DR - I've decided my vote.
>=20
> -Sara