Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115604
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: <CAOWwgpne5MEBxdvz=Q_zmRf=1abtQstMfpLXW4gbfp4+dRokfA@mail.gmail.com>
Date: Thu, 29 Jul 2021 07:10:30 +0200
Cc: Nicolas Grekas <nicolas.grekas@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-ID: <206327F4-8BE4-42F7-A120-F97453A5CA72@stitcher.io>
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
 <CAOWwgpne5MEBxdvz=Q_zmRf=1abtQstMfpLXW4gbfp4+dRokfA@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 internals

I wanted to apologise for the poor wording I used in my previous mail =
when I said "oversight". What I meant to say is what Nicolas described =
in his followup mail: feature freeze as a time to polish =
implementations. I personally consider nullability to be more of an =
implementation polishment, but I realise the syntax question makes it a =
more difficult question.

While my personal experience with 7.0 and the lack of nullability was =
really annoying, I'm sure we'll all survive if 8.1 doesn't include =
nullability support.=20

I just wanted to clarify those points, sorry if my previous mail caused =
any inconvenience.=20

Kind regards
Brent

> On 28 Jul 2021, at 09:29, Nicolas Grekas <nicolas.grekas@gmail.com> =
wrote:
>=20
> as proposed by Nikita and Joe, I'm submitting this late RFC for your
>> consideration for inclusion in PHP 8.1. Intersection types as =
currently
>> accepted are not nullable. This RFC proposes to make them so.
>>=20
>> I wrote everything down about the reasons why here:
>> https://wiki.php.net/rfc/nullable_intersection_types
>>=20
>> Please have a look and let me know what you think.
>>=20
>=20
> Hi everyone,
>=20
> Thank you for the contributions made to the discussion so far. I'm =
mostly
> AFK these days, hiking in Greece. That gives me time to think about
> comments made here, among other things :)
>=20
> Given the strong opposition from some, I considered withdrawing the =
RFC.
> But since I also see some nice support, I decided not to: even if the
> proposal is rejected, everyone should have the right to express their
> opinion, and the vote is the only option to not let only the most =
vocal or
> the most eloquent decide for the others.
>=20
> For the same reason, I'm not going to restrict the voting options to
> (X&Y)|null as some requested. I will change my mind if we spot that =
some
> syntax would put us in a corner. But so far and while I tried to be as
> careful as possible, all syntax proposals are future-proof to me. I =
get
> that some have strong coding style preferences, but that doesn't make =
a
> technical argument. It's true that deciding to allow no brackets won't
> allow us to force them later on. By why would we *force* them in the =
first
> place? While you may not like relying on it, operator precedence is a =
nice
> thing. I would hate having to put brackets around every single =
expression
> in PHP. For types, there are only two to three operators: we don't =
have to
> remember the full precedence table. And only one precedence makes =
sense
> anyway, so it's easy to remember. I'm not advocating that we should =
forbid
> brackets. Actually I'm going to vote for allowing both with and =
without
> them, because I don't want to force my preferred coding style to =
others.
>=20
> I do have a preference for using the `?` operator. It is compact and
> nullability *is* a flag. I'm reviewing code that use foo|null|bar, =
other
> that use foo|bar|null. That makes reading the code harder. About its
> precedence, I explained why I didn't need to be creative in the RFC: =
`?`
> has to be the lowest precedence type-operator. Any other options would =
make
> no sense from a logical pov. It would be so sweet and consistent to be =
able
> to use it all the time to express the nullability flag. I would mind =
if we
> allowed both `?` and `|null` btw.
>=20
> Intersection types are a really useful addition to the language, =
please
> don't suggest I framed it otherwise. I just thought that they would be =
a
> lot less useful if they were not nullable, especially considering that =
they
> could be part of public signatures that have to be maintained with BC =
in
> mind. I'm happy that some agree with this and share their experience =
about
> it.
>=20
> Nullability is a special beast in PHP. We have a range of operators
> dedicated to it. That's also why I think it deserves special care, and =
why
> I think it's important to have this discussion before 8.1 is out. To =
me,
> the feature freeze is also useful for this: polishing features that =
are
> about to be released. I don't see us rushing here.
>=20
> Let's do a careful and rational analysis of the proposal and vote on =
the
> very asked question. We do have enough time.
>=20
> TL;DR: I'm carefully looking for blockers and I'm calling for more =
examples
> if you spotted one!
>=20
> Cheers,
> Nicolas
>=20
>>=20