Re: [RFC][Vote] Typed Properties

I thought about a different approach :) - not-nullable typed properties must be explicitly initialized (or should be initialized implicitly by corresponding types, e.g. "int" should get default value int(0). ...) - nullable typed properties may be implicitly initialized by NULL (like untyped properties now). - unset() of typed properties should not be allowed This would allow to eliminate few weird run-time checks in VM and allow the most efficient usage of type information in Optimizar and JIT. Thanks. Dmitry. ________________________________ From: Joe Watkins <pthreads@pthreads.org> Sent: Wednesday, May 25, 2016 4:22:02 PM To: Nikita Popov Cc: Dmitry Stogov; PHP internals; Phil Sturgeon; Bob Weinand Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties 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.ppv@gmail.com<mailto:nikita.ppv@gmail.com>> wrote: On Wed, May 25, 2016 at 10:30 AM, Joe Watkins <pthreads@pthreads.org<mailto: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