Works as intended. https://wiki.php.net/rfc/typed_properties_v2

Typed properties are never initialized to a default null, unlike untyped properties. That is why $y and $z do not show up through get_object_vars: they are uninitialized. No, it cannot simply return null because (a) the properties do not have the value of null and (b) null may not even be a valid value for the property.

And as happens in some other languages, accessing an uninitialized property is not allowed.

As for the fatal error,
* ->y triggers __get, which returns null, which is valid for the "?string" type. No error.
* ->x triggers __get, which returns null, which is not valid for the "string" type. Error.

Do you have any particular (not quite so reduced) examples where this causes problems in practice? We had some issues with __set interaction that were addressed, so possibly there is some tweak in behavior possibly here as well, it's just not clear from the bug report what the actual issue is.

But generally, yes, initializing typed properties is obligatory, that's part of the point of having them. __get is called to allow some lazy initialization patterns, but shouldn't be relevant for most purposes.

Is the issue here that __get is called instead of immediately throwing a "trying to access uninitialized property" error?

@requinix
Restricting access to uninitialised typed variable is OK.
The problem is having the __get() called.


@nikic Yes, I do have. 

1. Consider a Request class from Laravel: https://github.com/laravel/framework/blob/master/src/Illuminate/Http/Request.php#L695

I extend it in an application to add custom behaviour, add a property. When the property is typed, I have a __get() call executed from the framework class, which is unexpected, because it differs from behavoir when the property has no type restriction.

2. __get() is extensively based in ORM implementations to map database data to the "virtual" properties.
https://github.com/illuminate/database/blob/master/Eloquent/Model.php#L1552
When we define a userland class property named after the table field name, we expect the __get() method not to be called. 

Virtial public properties may be a bad practice, but it is promoted extensively in several frameworks.

Having __get() called for uninitialized variables introduces a new variable state, and as such it needs a way to be processed. Same as isset(), property_exists(), we need some property_initialized() function.

So, sounds like we should have given __get() the same treatment as __set() in how it interacts with uninitialized typed properties. I'm not sure if we can still make this change at this point.

It would make sense to show a compile-time warning/notice for typed property declarations without initial value. Consider it for a later version, please.
If it is not possible, consider adding the way to check if the property is initialized, so framework authors could process this state in magic getters properly.

> It would make sense to show a compile-time warning/notice for typed property declarations without initial value. Consider it for a later version, please.

Certainly not. There is nothing wrong with a property that does not have an initial value. In fact nearly all properties shouldn't have one, as most properties get initialized based on constructor arguments.

Based on preliminary discussion we might change __get() behavior, so I'm reopening this. I'll prepare a patch asap.

Thank you. Sorry for filling this ticket up improperly, I did not expect attention.

I was experimenting with this behavior to allow lazy property initialization. For instance I can lazy load services in controllers. Now there is no other option, how to allow lazy initialize property. I have to stick back to annotations and dynamic properties.

You could add another magic method to allow that e.g. "__init", "__initProperty", "__getStrict", "__getTyped", etc. which would respect access modifiers.

You can see all my efforts in composer package bigbit/oddin. 
Version 1.* is using annotations and dynamic properties, version 2.* is using typed properties and __get.

@andrzej: Lazy property initialization is still supported and used by ProxyManager for example. To lazily initialize both typed and untyped properties, you must unset() them in the constructor.

Thank you for reply.

By doing unset first I have to explicitly put all the unset thing in constructor. In my opinion, this comes with time and resource penalty and makes code less readable.

Before fix (7.4.0):
class A {
  use GetMagicTrait;

  private Foo $a;
  private Bar $b;
  private Baz $z;
}

After fix (7.4.1+):
class A {
  use GetMagicTrait;

  private Foo $a;
  private Bar $b;
  private Baz $z;

  function __construct()
  {
    unset($this->$a, $this->b, $this->z);
  }
}

Anyway I have read the rfc for typed properties briefly and if I understand it correctly, this fix breaks it starting with section https://wiki.php.net/rfc/typed_properties_v2#uninitialized_and_unset_properties.

I would like to explain, what I want to achieve.
As of php7.4 not nullable typed properties can have 3 different states:

1. Not Initialized
2. Not Set (Initialized)
3. Set (Initialized)

So whenever I use unset I'm making its state unset (2) and __get is working.
Problem is, we cannot define typed property as unset, only "Not Initialized" or "Initialized"

I would like to be able to define unset state at the property instead of "Not Initialized". This would avoid using explicit unset in constructors.

I like typescript ! operator so final property definition could use one of:

class A {
  use GetMagicTrait;

  private Foo $a!;
  private Bar! $b;
  private ! Baz $z;
  private unset Bay $f;
}

where "private unset Foo $a" could be equivalent to shorter use with !.

Can I write RFC for this?
Are there any guidelines for RFCs?
What timeline could be expected for implementation?

Andrzej, dependency injection based on property types is contract programming, while annotation-based injection (you name it lazy loading) is a declarative programming.

These approaches should not be compared cause they follow ideologically different approach to system design. A sample of approaches is Yii vs Symfony.

I don't know they purpose of the code, but in general case I would advice against utilizing undocumented side effects in core code used in production, such as service locator and dependency injection. Low-level hacks are OK for debugging, mocking and testing utilites.