Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93112
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.179 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <D354BAB0.6E01F%fsb@thefsb.org>
References: <CAFMT4NoBqMrNSP_6J8nzA6E_+UChkjUz0jCvhXy_GE9RV3r2=Q@mail.gmail.com>
	<572E0A60.4090506@thefsb.org>
	<CAF+90c-91Lh3h4TPr=9jVubxEk8tpm06dTk1FviAfPGjcg_SdA@mail.gmail.com>
	<D354BAB0.6E01F%fsb@thefsb.org>
Date: Sun, 8 May 2016 16:33:13 +0200
Message-ID: <CAF+90c9_68OCw8Y0Xu6o6VJ1kieYiggSRjGSSU+hKrBcrS3tUQ@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=001a113d40026faa4105325592d2
Subject: Re: [PHP-DEV] Re: [RFC] Pre-vote notice for Nullable Types
From: nikita.ppv@gmail.com (Nikita Popov)

--001a113d40026faa4105325592d2
Content-Type: text/plain; charset=UTF-8

On Sun, May 8, 2016 at 3:54 PM, Tom Worster <fsb@thefsb.org> wrote:

> On 5/7/16, 1:19 PM, "Nikita Popov" <nikita.ppv@gmail.com> wrote:
>
> >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.
>
> The explanation is very clear. Thank you.
>
> Tom
>
>
> (Btw, I don't disagree about the inconsistency you mentioned. But I don't
> think it's a wild inconsistency, rather a justified one, given our
> context.)
>

At this point in time, with the current state of our type system, I agree
that this is not a wild inconsistency.

However, the type system is expanding. Typed properties are already under
discussion, and they would certainly support nullable types (in fact, the
proposal is currently blocked by us not having them yet). Generics are also
already under discussion (though far removed from a viable implementation).
They would, presumably, also support nullable types as generic type
parameters (or at least I don't see why not). Following this trend, we'd
end up in a situation where nullable types are supported *everywhere* --
apart from parameters.

Which is in my eyes a pretty bad spot to be in. At that point we'd have
gone from this being a "nullable return types" feature to a "nullable
types, but not allowed in parameters" feature, which is just weird.

Example for nullable types used in all of return types, parameter types and
property types.

class Node {
    private ?Node $left;
    private ?Node $right;
    private $value;
    public function __construct(?Node $left, ?Node $right, $value) {
        $this->left = $left;
        $this->right = $right;
        $this->value = $value;
    }
    public function getLeft() : ?Node {
        return $this->left;
    }
    public function getRight() : ?Node {
        return $this->right;
    }
    public function setLeft(?Node $node) {
        $this->left = $node;
    }
    public function setRight(?Node $node) {
        $this->right = $node;
    }
    // ...
}

Not having nullable types in parameters here would require you to either
drop the type altogether, or allow $node->setLeft() (eeeek), or
differentiate between $node->setLeft($nonNullNode) and $node->unsetLeft(),
which tends to be ugly for use in algorithmic transformations.

Regards,
Nikita

--001a113d40026faa4105325592d2--