> > 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. >
I disagree here. Properties are always null by default. The current patch disallows access to uninitialized variables only if they're not nullable, since null isn't a valid value then. I don't think having to explicitly set them to null is the think we want. And it's not what I'd expect given the current system. > 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? > These have always been different. `private $foo` has always been `null` by default, while `function($foo)` doesn't have a default value. > 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. > I think this is something unions should address. I'm personally still not a fan of union types, as they try to solve the wrong problem, mostly things like array not being instance of Traversable. Regards, Niklas > Please keep things consistent: If there is not default, there is no > default. > > Nikita >
