Morning Nikita,
That's pretty persuasive ...
Dmitry, what are your thoughts on those points ?
Cheers
Joe
On Wed, May 25, 2016 at 2:03 PM, Nikita Popov <nikita....@gmail.com> wrote:
> On Wed, May 25, 2016 at 10:30 AM, Joe Watkins <pthre...@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
>
