Re: [PHP-DEV] [RFC] Readonly Property Defaults

Hey Tim,

On 14.07.26 00:07, Tim Düsterhus wrote:
> Hi
>
> On 2026-07-09 21:18, Nick Sdot wrote:
>>> There is two options here:
>>>
>>> - The non-hooked unserialization path must also error out when 
>>> trying to unserialize into a readonly property with a default value.
>>> - __unserialize() must be able to unserialize into a readonly 
>>> property with a default value, similarly to __clone().
>>>
>>> But the current situation of “__unserialize() is less powerful than 
>>> the standard unserialization” is not acceptable, because it prevents 
>>> introducing `__unserialize()` on a class with a readonly property 
>>> with default values.
>>>
>>
>> It would not really have prevented using `__unserialize()` on a class 
>> with a readonly property with default values.
>
> That probably depends a little on the definition of “prevent”. 
> Technically you could implement `__unserialize()`, sure. But you would 
> be unable to unserialize into some of properties, which the native 
> unserializer would be able to.
>
>> But fair, I don't have a strong opinion here. Given that clone-with 
>> also allows modification of already initialised readonly properties 
>> your proposed option #2 is sound.
>
> Yes, I agree. clone-with already allows for the creation of object 
> with a different value than the default, so allowing this for 
> `__unserialize()` doesn't provide any new weird capabilities that 
> result in inconsistencies.
>
> ------
>
> As for the RFC, I have one more thing you could clarify: When using 
> constructor property promotion, the default value will remain the 
> default value of the parameter only and not suddenly also become the 
> default of a property. It's a bit orthogonal to this RFC, and I find 
> it reasonably obvious. But spelling it out to refresh everyone’s mind 
> is probably a good thing nevertheless.

Not exactly sure what you would like me to spell me out. It's indeed 
different things. I made a tiny addition to the non-goals. Let me know 
if that's enough or if you had something else in mind.

> Other than that, I don't have any further comments on the RFC and in 
> particular I don't see any more issues this would cause. Nevertheless, 
> I'm probably team “Abstain” when it goes to vote :-)
>
> Best regards
> Tim Düsterhus


--

Cheers
Nick