Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115756
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>
In-Reply-To: <CAF+90c-C+qvmNg8tasL+QpT_-VW2_amXOR9LEXcY91qDYU22cQ@mail.gmail.com>
Date: Mon, 16 Aug 2021 10:23:36 +0200
Message-ID: <CAOwTYAskxE0MUta2dJKUW8pxfbH4BYinPYtbY5myWNbAOjfcZw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: Deleu <deleugyn@gmail.com>, Tobias Nyholm <tobias.nyholm@gmail.com>, 
	Kalle Sommer Nielsen <kalle@php.net>, Patrick ALLAERT <patrickallaert@php.net>, 
	Nicolas Grekas <nicolas.grekas@gmail.com>, PHP Internals List <internals@lists.php.net>, 
	Ben Ramsey <ben@benramsey.com>
Content-Type: multipart/alternative; boundary="0000000000009a18f905c9a8eb01"
Subject: Re: [PHP-DEV] [VOTE] Nullable intersection types
From: krakjoe@gmail.com (Joe Watkins)

--0000000000009a18f905c9a8eb01
Content-Type: text/plain; charset="UTF-8"

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 good
idea.

Cheers
Joe





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 build
>> consensus this late in the cycle.
>>
>> The RFC is not passing currently so I don't think we actually need to do
>> 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 about
> 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 can
> take the fact that this is targeting 8.1 into consideration in their choice
> -- I suspect that a lot of the "no" votes here are specifically due to
> that, not because they generally dislike support for nullable intersection
> 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 anytime,
> 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
>

--0000000000009a18f905c9a8eb01--