Re: [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