Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115765
MIME-Version: 1.0
References: <CAOWwgpn0ZKV1ZA5pErEjwQVXsHpyb9zoA1VT7DsHC0=SeVeXJg@mail.gmail.com>
 <CACwt+Je+t0p9eF+6Q3Urk7b4k6qPQtkRRqBg3P+tEb_t_W2H_g@mail.gmail.com>
 <72785D6F-6803-49BB-B575-01061699ABF4@gmail.com> <CAJW__o3yDUB1TU9sLmKfs3CHS2V660S3uyGDffEojzcwYFGKhw@mail.gmail.com>
 <448DAADA-C819-457F-ABBF-F942128B2830@gmail.com> <CADK1yXL6urFvFCy3zfcMiOD5So_wk4dMSEJSkS-O5JKD=QPqnw@mail.gmail.com>
 <CAOwTYAu_gA7Lre-xmzMV1Jny4r23ud2OFis7GSPd9Z8=Bh1QnQ@mail.gmail.com>
 <CAF+90c-C+qvmNg8tasL+QpT_-VW2_amXOR9LEXcY91qDYU22cQ@mail.gmail.com> <CAOwTYAskxE0MUta2dJKUW8pxfbH4BYinPYtbY5myWNbAOjfcZw@mail.gmail.com>
In-Reply-To: <CAOwTYAskxE0MUta2dJKUW8pxfbH4BYinPYtbY5myWNbAOjfcZw@mail.gmail.com>
Date: Thu, 19 Aug 2021 12:25:11 +0200
Message-ID: <CAOWwgpnAhJ7-t_o429tN_+=JqRJDsvha0dvSxNEMyZVtcocCAw@mail.gmail.com>
To: Joe Watkins <krakjoe@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, Deleu <deleugyn@gmail.com>, 
	Tobias Nyholm <tobias.nyholm@gmail.com>, Kalle Sommer Nielsen <kalle@php.net>, 
	Patrick ALLAERT <patrickallaert@php.net>, PHP Internals List <internals@lists.php.net>, 
	Ben Ramsey <ben@benramsey.com>
Content-Type: multipart/alternative; boundary="000000000000fa580905c9e6f70b"
Subject: Re: [PHP-DEV] [VOTE] Nullable intersection types
From: nicolas.grekas@gmail.com (Nicolas Grekas)

--000000000000fa580905c9e6f70b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

>
> On Mon, 16 Aug 2021 at 10:04, Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> On Mon, Aug 16, 2021 at 9:45 AM Joe Watkins <krakjoe@gmail.com> wrote:
>>
>>> Morning all,
>>>
>>> The initial RFC was clear that nullability was not supported, however
>>> that
>>> doesn't seem to be have widely understood.
>>>
>>> When I said we should move forward I did imagine that there was some
>>> consensus about the syntax we should use if we were to support
>>> nullability.
>>>
>>
>> Based on the vote, it looks like there's a pretty clear consensus on
>> (X&Y)|null :)
>>
>>
>>> As this conversation has progressed it has become clear that we don't
>>> have
>>> that consensus, and many people are just not comfortable trying to buil=
d
>>> consensus this late in the cycle.
>>>
>>> The RFC is not passing currently so I don't think we actually need to d=
o
>>> anything, except prepare to deploy the feature that was voted in, pure
>>> intersections.
>>>
>>> The RFC should be allowed to complete, it's gathering important data.
>>>
>>> In the end, I'm not as happy to make an exception as I was when the
>>> discussion started.
>>
>>
>> FWIW I think that if we granted an exception for this once, we shouldn't
>> go back on it. Maybe there should have been some discussion among RMs ab=
out
>> this, but I think your agreement was interpreted (at least by me and
>> presumably Nicolas) as it being fine to go forward with this RFC from a
>> release management perspective. Now that the vote is underway, people ca=
n
>> take the fact that this is targeting 8.1 into consideration in their cho=
ice
>> -- I suspect that a lot of the "no" votes here are specifically due to
>> that, not because they generally dislike support for nullable intersecti=
on
>> types.
>>
>> As a meta note, I think it's important that we're open to minor changes
>> to new features during the pre-release phase -- it's purpose is not just
>> implementation stability. In fact, we can fix implementation bugs anytim=
e,
>> but usually can't do the same with design issues. (Of course, in this
>> particular case the proposed change is backwards-compatible, so there is=
 no
>> strict requirement to make a change before the stable release.)
>>
>> Regards,
>> Nikita
>>
>
Morning Nikita, all,
>
> The exception was granted to ratify consensus that I thought we had - and
> that one of the two primary votes on the current RFC seems to support.
>
> However, the RFC we got was something that contained multiple primary
> votes - we must consider the first two votes primary, we don't want to
> choose syntax on a 50% majority.
>
> At the moment it looks like we don't have a consensus that adding
> nullability (at this late stage) is important.
>
> I too think it's important to be flexible in this stage of the cycle, but
> I look at the opposition to making this change now and that degrades my
> confidence that making the change this late even if it does pass is a goo=
d
> idea.
>
> Cheers
> Joe
>

What a mess! I feel so disappointed by the lack of clarity of the processes
here.

The RFC was granted a "go" by a release manager, but suddenly, in the
middle of the vote, another release manager raised an objection to this
grant!? This should have been discussed before between release managers.
Also, this "go" is now apparently revoked based on the partial results of
the vote. This is obviously interfering with the vote itself! I'm not
blaming any individuals, but some processes should clarify how this is
supposed to work. At least please coordinate together on such topics! =F0=
=9F=99=8F

The processes also lack clarity about what the feature freeze is supposed
to mean. We're having a metadiscussion about whether this RFC can target
8.1 or not, and many ppl stated that they would vote against it not because
they don't want nullability, but because they don't want it in 8.1, or
because they feel it's too late for 8.1. I can't blame them for that, but
what is "feature freeze" supposed to mean if we aren't allowed to discuss,
alter, or even revert not-yet-released features?!? This should be shielded
by some consensus on what is allowed during the feature freeze. On my side:
anything that is not yet released should be re-discussable until either
beta or RC stage. If we choose to go with beta, we should give more time
between the start of the feature freeze and the first beta, precisely to
fix what happened to this RFC, aka to give a window for the community (me
here) to play with the soon-to-be features and give feedback.

Based on the partial results of the vote, we could conclude that the
consensus is to 1. not allow nullability and 2. force bracket around
(X&Y)|null. I can't read this as anything else than ppl voting not on the
RFC, but on this metadiscussion about the feature freeze + some fear that
we might put ourselves in a corner with the syntax.

The RFC should be allowed to complete, it's gathering important data.
>

Because of what I just wrote about, I don't think we can rely on any data
here. The discussion should be rebooted from scratch for me. Apparently, we
need the full syntax for composite types to decide for the syntax for
nullable intersection types. =C2=AF\_(=E3=83=84)_/=C2=AF

Now, I don't know what to do. The vote started and is not looking good for
the proposal. Some will say that I didn't want to see it fail if I withdraw
it. But honestly, with all those interferences, I'm not sure the conditions
are met to have a fair vote.

Please advise (release managers mainly I suppose, since you're the only
ones having some sort of official authority here).

Nicolas

--000000000000fa580905c9e6f70b--