Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93501
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAL=_i_kze8MNSmpg4WT+EJCRPmvty=8DA6DkuHSx+WCBzJjytg@mail.gmail.com>
References: <CAL=_i_mcJoFnPgeU5FQCJN=SDYnNK7Jz8zoVMv9EMuWaGRYSMg@mail.gmail.com>
	<BY2PR0201MB17845690B6386D75AF4C3D79BF4F0@BY2PR0201MB1784.namprd02.prod.outlook.com>
	<CAL=_i_=EqNoHvXmY+RdQW-reC4YF8AkuWFtGGJGOOSqX4a010g@mail.gmail.com>
	<cfe8404a-54f6-24b7-0ba8-8f807c820821@zend.com>
	<CAL=_i_kze8MNSmpg4WT+EJCRPmvty=8DA6DkuHSx+WCBzJjytg@mail.gmail.com>
Date: Wed, 25 May 2016 15:03:00 +0200
Message-ID: <CAF+90c9cBqKfy_q5rME1u56Rq366niYUBDTY+3_2iFJSZD9fDA@mail.gmail.com>
To: Joe Watkins <pthreads@pthreads.org>
Cc: Dmitry Stogov <dmitry@zend.com>, PHP internals <internals@lists.php.net>, 
	Phil Sturgeon <pjsturgeon@gmail.com>, Bob Weinand <bwoebi@php.net>
Content-Type: multipart/alternative; boundary=001a1140723a1b862a0533aa4b8d
Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties
From: nikita.ppv@gmail.com (Nikita Popov)

--001a1140723a1b862a0533aa4b8d
Content-Type: text/plain; charset=UTF-8

On Wed, May 25, 2016 at 10:30 AM, Joe Watkins <pthreads@pthreads.org> wrote:

> Morning Dmitry,
>
>    > I made this check(s) to be invariant. You may like to do this
> differently...
>
>    I think this is what everyone expects, isn't it ?
>
>    I did omit to mention that part ...
>
>    > RFC doesn't define how uninitialized nullable typed properties should
> behave.
>
>   It does:
>
>    > *Nullable typed properties will not raise an exception when accessed
> before initialization.*
>

I don't agree with this choice, for three reasons:

a) This unnecessarily restricts what can be expressed in the type system.
With these semantics it will no longer be possible to express that a
property should be nullable, but have no default value. This situation is
not uncommon in practice, in particular anytime you have a nullable
constructor argument, you will want the corresponding property to be
nullable without a default, to ensure that it is explicitly initialized.

b) This directly contradicts the meaning of ?Type for parameters. For
parameters ?Type means that it's a nullable parameter **without a default
value**. That's the very thing that distinguishes it from the Type $prop =
null syntax. And now ?Type for properties should mean the exact opposite?

c) If you view this in a larger scope of union types, this *special case*
becomes even more weird. Why does the particular union Type|null get
special treatment, while all other unions don't? Or is it actually not
specific to "null", but to single value types? E.g. if we also allowed
Type|false, would that also receive an implicit false default value? What
about the type null|false? Does that get an implicit default, and if so,
which? I realize this is not quite in scope for type properties, but the
further evolution of the type system should be kept in mind.

Please keep things consistent: If there is not default, there is no default.

Nikita

--001a1140723a1b862a0533aa4b8d--