promoted property in serialized object behaves unexpected

[R4c00n]

Description

The following code:

<?php
class Foo {
    public string $bar = 'a';
    public ?string $baz = null;
    
    public function __construct(public readonly ?string $x = null) {
        
    }
}

$fooSerialized = 'O:3:"Foo":1:{s:3:"bar";s:1:"a";}a';
$fooUnserialized = unserialize($fooSerialized);

var_dump($fooUnserialized->bar); // works because exists in serialized string
var_dump($fooUnserialized->baz); // works because regular typed property, even if not existing in serialized string
var_dump($fooUnserialized->x); // Doesn't work

Resulted in this output:

string(1) "a"
NULL

Fatal error: Uncaught Error: Typed property Foo::$x must not be accessed before initialization in /in/4d6XG:18
Stack trace:
#0 {main}
  thrown in /in/4d6XG on line 18

Process exited with code 255.

But I expected this output instead:

string(1) "a"
NULL
NULL

See also https://3v4l.org/4d6XG#v8.2.6 (all versions)

PHP Version

PHP 8.2.6

Operating System

No response

[iluuu1994]

The constructor isn't executed on unserialize, and the default value is only assigned in the constructor. If there was a real default value for a readonly property you would be unable to change it in the constructor. You can use the __unserialize magic method to provide a default value if for some reason the serialized data doesn't contain it.

[R4c00n]

If there was a real default value for a readonly property you would be unable to change it in the constructor.

The same behavior can be observed with a writable promoted property.

I am also not sure if I want to call this a bug or not. But it is certainly unexpected. (for me/us at least)
But I guess it is documented here https://wiki.php.net/rfc/constructor_promotion#desugaring

[damianwadley]

The key here is that the default value applies to the constructor's parameter itself - not to the promoted property. The property does not have a default, so if there isn't data to use in the serialized string then the property will remain unassigned, and combined with a type means it remains in the uninitialized state.

If you remove the ?string type (as well as readonly since that requires a type) then the code works as expected.

[bukka]

As this is documented behaviour I changed to feature request.