Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115601
MIME-Version: 1.0
References: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
In-Reply-To: <CAOWwgp=B7-AvMao0POCF_h_A3A4voHNA_BsjfonBQ8yDHb0v-A@mail.gmail.com>
Date: Wed, 28 Jul 2021 10:29:18 +0300
Message-ID: <CAOWwgpne5MEBxdvz=Q_zmRf=1abtQstMfpLXW4gbfp4+dRokfA@mail.gmail.com>
To: PHP Internals List <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000078e3b105c829f25b"
Subject: Re: [RFC] Nullable intersection types
From: nicolas.grekas@gmail.com (Nicolas Grekas)

--00000000000078e3b105c829f25b
Content-Type: text/plain; charset="UTF-8"

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.
>
> I wrote everything down about the reasons why here:
> https://wiki.php.net/rfc/nullable_intersection_types
>
> Please have a look and let me know what you think.
>

Hi everyone,

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 :)

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.

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.

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.

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.

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.

Let's do a careful and rational analysis of the proposal and vote on the
very asked question. We do have enough time.

TL;DR: I'm carefully looking for blockers and I'm calling for more examples
if you spotted one!

Cheers,
Nicolas

>

--00000000000078e3b105c829f25b--