Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115775
User-Agent: Cyrus-JMAP/3.5.0-alpha0-1118-g75eff666e5-fm-20210816.002-g75eff666
Mime-Version: 1.0
Message-ID: <fb64456e-e3ee-4faa-a2f3-032038d9863f@www.fastmail.com>
In-Reply-To: 
 <CACwt+JcX9NQ7_xn4HVwnQ=g3sqJ4iitGyXumrjnq-JNtuz1j=g@mail.gmail.com>
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>
 <CAOWwgpnAhJ7-t_o429tN_+=JqRJDsvha0dvSxNEMyZVtcocCAw@mail.gmail.com>
 <CACwt+JcX9NQ7_xn4HVwnQ=g3sqJ4iitGyXumrjnq-JNtuz1j=g@mail.gmail.com>
Date: Mon, 23 Aug 2021 09:21:37 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Nullable intersection types
From: larry@garfieldtech.com ("Larry Garfield")

On Sun, Aug 22, 2021, at 5:42 PM, Patrick ALLAERT wrote:

> Either extra time, or having a way to influence the schedule of the
> releases.
> For now, we work with a fixed schedule and don't know (at least: me) h=
ow
> strict we must stick to it.
>=20
> The fixed schedule of the releases is what makes me more comfortable w=
ith
> the idea of reverting a new feature rather than extending the scope of=
 one.

Speaking from the outside:

Joe stated in an earlier email very clearly that because this was viewed=
 as a "possible bug fix" it was given permission to run post-freeze.  Th=
ere was no dispute in my mind at least whether the RFC was valid.

That said, if voters are of the opinion that "the cure is worse than the=
 disease" on this one (eg, because it didn't take into account larger qu=
estions around compound types that will have to come later, and so may m=
ake things more difficult in the future, or because the reflection API i=
sn't fully thought through, etc.), or that it feels too rushed, that is =
entirely their right to vote no on it on those grounds.  That's basicall=
y a summary of my No vote: I'd rather have non-nullable intersections fo=
r now than something that is going to make life more difficult in the fu=
ture for full mixed types.


> > 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 o=
n 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. Apparen=
tly, we
> > need the full syntax for composite types to decide for the syntax for
> > nullable intersection types. =C2=AF\_(=E3=83=84)_/=C2=AF
> >
>=20
> I also think that we can't rely on the data for the reason you mention=
 even
> if I intended to vote "no" on the feature, not on the targeted version=
 of
> PHP, I may be the exception there.

That's not different than any other RFC.  We never differentiate "no on =
the concept" from "no on the implementation" from "no on some particular=
 detail that's really really important."  That's data we almost never ge=
t, unless someone volunteers it on their own.  This RFC is no different =
in that regard.

> > Now, I don't know what to do. The vote started and is not looking go=
od for
> > the proposal. Some will say that I didn't want to see it fail if I w=
ithdraw
> > it. But honestly, with all those interferences, I'm not sure the con=
ditions
> > are met to have a fair vote.

I have to disagree.  Given Joe's earlier message, the RFC was legal and =
allowed to proceed.  "I still think it's too late" is entirely someone's=
 right to justify a No vote.  That's not interference, that's the voter'=
s viewpoint and it should be respected.

--Larry Garfield