Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93108
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <572E0A60.4090506@thefsb.org>
References: <CAFMT4NoBqMrNSP_6J8nzA6E_+UChkjUz0jCvhXy_GE9RV3r2=Q@mail.gmail.com>
	<572E0A60.4090506@thefsb.org>
Date: Sat, 7 May 2016 19:19:10 +0200
Message-ID: <CAF+90c-91Lh3h4TPr=9jVubxEk8tpm06dTk1FviAfPGjcg_SdA@mail.gmail.com>
To: Tom Worster <fsb@thefsb.org>
Cc: Levi Morrison <levim@php.net>, internals <internals@lists.php.net>, 
	Dmitry Stogov <dmitry@zend.com>
Content-Type: multipart/alternative; boundary=001a113f43dc0f7046053243c6b0
Subject: Re: [PHP-DEV] Re: [RFC] Pre-vote notice for Nullable Types
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113f43dc0f7046053243c6b0
Content-Type: text/plain; charset=UTF-8

On Sat, May 7, 2016 at 5:31 PM, Tom Worster <fsb@thefsb.org> wrote:

> On 5/6/16 3:41 PM, Levi Morrison wrote:
>
>> The [RFC for Nullable Types][1] is going to go into the voting phase
>> soon. There have been a few changes to the RFC in the meantime:
>>
>>    - More example for documentation's sake
>>    - The vote is now split into two parts: one for nullable parameter
>> types and one for nullable return types.
>>
>
> The vote counting surprises me. Say, for the sake of argument, a
> hypothetical nullable returns RFC were to pass with 2/3. After that a 2nd
> hypothetical RFC for nullable parameters goes to vote. This 2nd RFC would
> need 2/3 to pass. Your RFC defines the same two separate language changes
> as two votes but one of them requires only a majority.
>
> Also, could you clarify in the RFC text how the voting works. For example,
> is it the case that the entire nullable parameter vote is discarded if the
> nullable return vote does not pass?
>
> Tom
>

This RFC has one primary vote and one secondary vote. The primary vote
determines whether we want to add nullable types to our type system. The
secondary vote decides how precisely this will happen, in this instance
deciding whether nullable types will be restricted to return types only or
not. This is a standard voting layout, with precedent in a number of other
RFCs.

The reason why the second vote must use a 1/2 majority is symmetry. You, as
somebody who does not like nullable parameter types, argue from a
perspective of one 2/3 majority RFC for introducing nullable returns and
another 2/3 majority RFC for introducing nullable params. I, as somebody
who thinks supporting this syntax only for returns is wildly inconsistent,
will argue from a perspective of a 2/3 majority RFC for introducing
nullable *types* and another 2/3 majority RFC for restricting them to
return types only. Depending on the perspective this would require either a
2/3 majority, or a 1/3 "majority" for unrestricted nullable types. Using a
1/2 majority vote ensures that there is no bias for either choice.

Regards,
Nikita

--001a113f43dc0f7046053243c6b0--