Hi, This mail turned out to look quite a lot like a rant - sorry about that. I can assure you I am genuinely looking for answers on the questions that follow ...
https://3v4l.org/Lq5dA/rfc#tabs (an example is from the RFC itself) It doesn't make sense to me, for numerous reasons: 1. Why are any magic methods called for public (and already declared) properties, especially from inside the object's constructor? 2. Even if there's a sane reason for that first point, a __get() call may not even attempt to access the property in question, so why is its return value taken into account? 3. Why does unset($this->bar) call $this->__get('bar') and not $this->__unset('bar'), like it happens for all properties currently? 4. Furthermore, why is unset($this->bar) valid on initialized properties, but not on uninitialized ones? I also still feel that completely preventing a typed property to "return NULL" in any shape or form is a way too opinionated decision ... I can understand disabling explicit NULL assignments. And I don't particularly like it, I also understand throwing TypeError for direct access on an unitialized property: class Foo { public int $bar; } $foo = new Foo(); $this->bar = null; if ($this->bar === null) {} // ^ I agree, both of these SHOULD throw TypeError However, I see no reason why this shouldn't work: class Foo { public int $bar = null; } $foo = new Foo(); is_null($foo->bar) && doSomething(); That's no longer a question of should uninitialized properties be accessible; it's explicit - the developer writing this *wants* the property to have NULL at least as the default value. With all the "consistency" arguments thrown against virtually all proposals so far, why is this one inconsistent with typed parameters? Sure, the RFC half-addresses this question by saying that it intentionally doesn't touch on the subject of nullability because of the eventual union types feature, but that feature is not even officially proposed yet. Theoretically, it may not ever change its status from "Draft", let alone be accepted, but even if so - I don't see it disallowing function foo(int $bar = null) {}, so does it apply here? And finally, and most importantly - throwing a TypeError even on an isset() ... that's not even a function call. Some may prefer to think of isset() as if it was an inverted is_null(), but we all know it's not quite the same and it doesn't emit notices for undefined variables. So why should it throw TypeError for properties? Why can't we at least have a way to *check* if a property was ever initialized? Cheers, Andrey.
