Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115890
MIME-Version: 1.0
References: <CADK1yXLZzoOjjNcpZ5ZtV9kSNgw4=SW9G74o26eLdAYV5cDzAQ@mail.gmail.com>
 <alpine.DEB.2.23.453.2108241825130.2773@singlemalt.home.derickrethans.nl>
 <CADK1yXL=HdA5jF9F09vAgvZYzDpxcuN-1vxudwmZ6BXkjtuPKg@mail.gmail.com>
 <C7EF7C8B-A617-4C44-AAD5-B970098EC5AB@php.net> <CADK1yXLuSkMmfBumC4y9g4oP5dP06jgcLeh6S8K57Lum_3i8wQ@mail.gmail.com>
 <48D54138-2930-4935-B979-9A9DE9B403F1@gmail.com> <CA+kxMuT5JEbd9YUAnGx1+Qnv3D4tyiakPkPfbJTc=KRWedunkA@mail.gmail.com>
 <828C15A4-86D3-43EE-960F-05B4EA7DEB23@gmail.com>
In-Reply-To: <828C15A4-86D3-43EE-960F-05B4EA7DEB23@gmail.com>
Date: Fri, 27 Aug 2021 22:55:17 -0700
Message-ID: <CAMrTa2G=nkfM_c3Q-E5H-EG96QA8z+xddkNtcLP5N-XUHs9FNw@mail.gmail.com>
To: Tobias Nyholm <tobias.nyholm@gmail.com>
Cc: Dan Ackroyd <Danack@basereality.com>, Nicolas Grekas <nicolas.grekas+php@gmail.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000bb8d9905ca983ff7"
Subject: Re: [PHP-DEV] Guidelines for RFC post feature-freeze
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000bb8d9905ca983ff7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Aug 27, 2021 at 11:11 AM Tobias Nyholm <tobias.nyholm@gmail.com>
wrote:

>
> But I do agree with you. The process would have been way better if they
> said =E2=80=9Cno". Or if they clearly and unanimously said =E2=80=9Cyes=
=E2=80=9D which would remove
> focus on =E2=80=9Cit feels rushed=E2=80=9D and =E2=80=9Cwe can=E2=80=99t =
because of feature freeze=E2=80=9D.
> This is the the extended power I would like the RMs (as a group) to have.
>
> To be clear, Im not suggesting they should veto every RFC. Just changes
> during feature freeze. Since RMs are experienced open source developers, =
Im
> sure they know to ask for help privately whenever they need it.
>
> // Tobias
>

I do not believe the reason people felt it was rushed is because of
ambiguity from RMs. The reason people felt it was rushed is because:

1. It was a special case of combination types, which voters understood to
be a feature targeting 8.2
2. Because it was a feature understood to be targeting 8.2, there was
insufficient research into what was technically possible or favorable for
general combination types.
3. Because it was a feature understood to be targeting 8.2, it had been
specifically excluded from the intersection types RFC.

None of those would have been addressed by anything from the RMs, because
all of those have to do with the voters' understanding of what the roadmap
is and what they had previously voted on. The people who had voted to
include intersection types had very specifically been told that they were
not nullable, and voted for it anyway, knowing that nullability would come
when anticipated support for combination types came.

This is my understanding of the situation, in any case.

Jordan

--000000000000bb8d9905ca983ff7--