Hey Internals,
I would like to present a tiny, five-line-removal RFC allowing default values on readonly properties.
Allowing default values on readonly class properties enables creating a strict contract for implementation property values that will not change at runtime -- as in, constant-like behaviour with contract. I would love doing that.
Please find the RFC text here: PHP: rfc:readonly_property_defaults
--
Cheers
Nick
Hi
On 2026-07-04 12:03, Nick Sdot wrote:
I would like to present a tiny, five-line-removal RFC allowing default values on readonly properties.
Allowing default values on readonly class properties enables creating a strict contract for implementation property values that will not change at runtime -- as in, constant-like behaviour with contract. I would love doing that.
Please find the RFC text here: PHP: rfc:readonly_property_defaults
Thank you, the proposal makes sense to me. I have just some requests for clarification:
1.
Can you add a “clone-with” example to the “Interaction with clone” section? I assume that “clone-with” will also just work for the same reasons, but it makes sense to spell it out.
2.
Can you spell out the unserialization behavior with an example. “Unserialisation continues to use the existing object hydration semantics and is not changed by this RFC” is not clear to me, because from my mental model unserialization first does a `newInstanceWithoutConstructor()` and then fills in the properties based on the serialized data. Thus a readonly field with a default value would already be initialized, which means that filling in the serialized data would fail, which I think is not a situation we have so far.
3.
In the “Interaction with asymmetric visibility” section, the example would be stronger with a `public(set)` instead of `private(set)`, because with `private(set)` the example would fail either way, since the global scope has no access to the property.
4.
Minor polishing remark in “Interaction with traits”: The opening PHP tag is missing in the example.
Best regards
Tim Düsterhus
Hey Tim,
thanks for the feedback!
On 09.07.26 16:12, Tim Düsterhus wrote:
Hi
On 2026-07-04 12:03, Nick Sdot wrote:
I would like to present a tiny, five-line-removal RFC allowing default values on readonly properties.
Allowing default values on readonly class properties enables creating a strict contract for implementation property values that will not change at runtime -- as in, constant-like behaviour with contract. I would love doing that.
Please find the RFC text here: PHP: rfc:readonly_property_defaults
Thank you, the proposal makes sense to me. I have just some requests for clarification:
1.
Can you add a “clone-with” example to the “Interaction with clone” section? I assume that “clone-with” will also just work for the same reasons, but it makes sense to spell it out.
Spelled it out and added a test for it.
2.
Can you spell out the unserialization behavior with an example. “Unserialisation continues to use the existing object hydration semantics and is not changed by this RFC” is not clear to me, because from my mental model unserialization first does a `newInstanceWithoutConstructor()` and then fills in the properties based on the serialized data. Thus a readonly field with a default value would already be initialized, which means that filling in the serialized data would fail, which I think is not a situation we have so far.
At the time `__unserialize` is called the object exists, and the property is initialised with the default value. So it fails in the same way a re-assignment in the constructor or reflection `setValue()` will fail. So, I wouldn't say "not a situation we have so far", but agree that spelling it out cannot be wrong. RFC section is updated, and your PR comment example added as a test!
3.
In the “Interaction with asymmetric visibility” section, the example would be stronger with a `public(set)` instead of `private(set)`, because with `private(set)` the example would fail either way, since the global scope has no access to the property.
You are right. Changed.
4.
Minor polishing remark in “Interaction with traits”: The opening PHP tag is missing in the example.
Fixed!
Best regards
Tim Düsterhus
--
Cheers
Nick
Hi
On 2026-07-09 13:58, Nick Sdot wrote:
At the time `__unserialize` is called the object exists, and the property is initialised with the default value. So it fails in the same way a re-assignment in the constructor or reflection `setValue()` will fail. So, I wouldn't say "not a situation we have so far", but agree that spelling it out cannot be wrong. RFC section is updated, and your PR comment example added as a test!
Yes, it would be a situation we do not yet have so far: As far as I can tell there is no way for a readonly property to be preinitialized when unserialization happens. This means that it is not not observable that the non-hooked serialization path ignores `readonly`. What is effectively guaranteed right now is that using a custom `__unserialize()` hook that loops over the given array and assigns all properties will behave identically to non-hooked serialization. This would no longer be the case as of this RFC.
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.
Best regards
Tim Düsterhus
Hey Tim
On 09.07.26 20:12, Tim Düsterhus wrote:
Hi
On 2026-07-09 13:58, Nick Sdot wrote:
At the time `__unserialize` is called the object exists, and the property is initialised with the default value. So it fails in the same way a re-assignment in the constructor or reflection `setValue()` will fail. So, I wouldn't say "not a situation we have so far", but agree that spelling it out cannot be wrong. RFC section is updated, and your PR comment example added as a test!
Yes, it would be a situation we do not yet have so far: As far as I can tell there is no way for a readonly property to be preinitialized when unserialization happens. This means that it is not not observable that the non-hooked serialization path ignores `readonly`. What is effectively guaranteed right now is that using a custom `__unserialize()` hook that loops over the given array and assigns all properties will behave identically to non-hooked serialization. This would no longer be the case as of this RFC.
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. 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.
I updated the PR and RFC
Best regards
Tim Düsterhus
--
Cheers
Nick
On Sat, Jul 4, 2026, at 5:03 AM, Nick Sdot wrote:
Hey Internals,
I would like to present a tiny, five-line-removal RFC allowing default
values on readonly properties.Allowing default values on readonly class properties enables creating a
strict contract for implementation property values that will not change
at runtime -- as in, constant-like behaviour with contract. I would love
doing that.Please find the RFC text here:
PHP: rfc:readonly_property_defaults
I had been planning to say "meh, doesn't seem like it would hurt anything," but as Tim pointed out with unserialize, it potentially could hurt something. That makes me skeptical.
I also want to call out, as the RFC notes, that this is already a solved problem with private(set). It's not quite the same as readonly, but for most practical purposes it's close enough and already addresses the use case this RFC.
--Larry Garfield
Hey Larry,
On 11.07.26 06:02, Larry Garfield wrote:
On Sat, Jul 4, 2026, at 5:03 AM, Nick Sdot wrote:Hey Internals, I would like to present a tiny, five-line-removal RFC allowing default values on readonly properties. Allowing default values on readonly class properties enables creating a strict contract for implementation property values that will not change at runtime -- as in, constant-like behaviour with contract. I would love doing that. Please find the RFC text here: [https://wiki.php.net/rfc/readonly_property_defaults](https://wiki.php.net/rfc/readonly_property_defaults)I had been planning to say "meh, doesn't seem like it would hurt anything," but as Tim pointed out with unserialize, it potentially could hurt something. That makes me skeptical. I also want to call out, as the RFC notes, that this is already a solved problem with private(set). It's not quite the same as readonly, but for most practical purposes it's close enough and already addresses the use case this RFC.
Thanks for the feedback.
I have to push back. It is not a solved problem. In fact, private(set) is not only “not quite the same”. Both features solve fundamentally different problems – private(set) has a foot gun readonly does not have.
Because this point comes up repeatedly here is a concrete example:
final class PipelineOne // private(set)
{
public private(set) array $orderedPipelineSteps = [
\Thing\StepDoSomethingTwo::class,
\Thing\StepAtReportBeginning::class,
\Thing\StepDoSomethingOne::class,
];
public function describe(): array
{
\sort($this->orderedPipelineSteps); // whoopsie, should have copied first
$ordered = $this->orderedPipelineSteps;
// do stuff
return $ordered;
}
}
final readonly class PipelineTwo // readonly
{
public function __construct(
public array $orderedPipelineSteps = [
\Thing\StepDoSomethingTwo::class,
\Thing\StepAtReportBeginning::class,
\Thing\StepDoSomethingOne::class,
],
) {}
public function describe(): array
{
\sort($this->orderedPipelineSteps); // whoopsie, should have copied first
$ordered = $this->orderedPipelineSteps;
// do stuff
return $ordered;
}
}
// ###################### private(set) ######################
$one = new PipelineOne();
\var_dump($one->describe());
// array(3) {
// [0]=>
// string(27) “Thing\StepAtReportBeginning” // good, now ordered
// [1]=>
// string(24) “Thing\StepDoSomethingOne”
// [2]=>
// string(24) “Thing\StepDoSomethingTwo”
//}
\var_dump($one->orderedPipelineSteps);
// array(3) {
// [0]=>
// string(27) “Thing\StepAtReportBeginning” // whoopsie, this should NOT be first!
// [1]=>
// string(24) “Thing\StepDoSomethingOne”
// [2]=>
// string(24) “Thing\StepDoSomethingTwo”
//}
// ###################### readonly ######################
$two = new PipelineTwo();
\var_dump($two->describe());
//Fatal error: Uncaught Error: Cannot indirectly modify readonly property PipelineTwo::$orderedPipelineSteps
With private(set) accidental mutation is legal. With readonly, modification after initialisation is illegal. Both are great and useful features, but private(set) only controls visibility not mutation. As the above example proves, readonly is strict when it comes to mutation and would have prevented the bug while private(set) happily ignores it because mutation happens from within the class. With readonly it would have been surfaced that I did:
\sort($this->orderedPipelineSteps); // whoopsie, mutated
$ordered = $this->orderedPipelineSteps;
instead of:
$ordered = $this->orderedPipelineSteps;
\sort($ordered);
This alone is reason enough to use readonly over private(set); less verbosity is a cherry on top.
Note: only to make the example copy & work without the PR branch I used constructor property promotion here. With the RFC, PipelineTwo can declare the property default directly, without allowing outside modification.
–
Cheers
Nick
(sorry for the double post; for some reason Thunderbird messed up formatting on web in the last attempt)
Hey Larry,
On 11.07.26 06:02, Larry Garfield wrote:
> On Sat, Jul 4, 2026, at 5:03 AM, Nick Sdot wrote:
>> Hey Internals,
>>
>> I would like to present a tiny, five-line-removal RFC allowing default
>> values on readonly properties.
>>
>> Allowing default values on readonly class properties enables creating a
>> strict contract for implementation property values that will not change
>> at runtime -- as in, constant-like behaviour with contract. I would love
>> doing that.
>>
>> Please find the RFC text here:
>> PHP: rfc:readonly_property_defaults
> I had been planning to say "meh, doesn't seem like it would hurt anything," but as Tim pointed out with unserialize, it potentially could hurt something. That makes me skeptical.
>
> I also want to call out, as the RFC notes, that this is already a solved problem with private(set). It's not quite the same as readonly, but for most practical purposes it's close enough and already addresses the use case this RFC.
Thanks for the feedback.
I have to push back. It is not a solved problem. In fact, `private(set)` is *not* only "not quite the same". Both features solve fundamentally different problems -- `private(set)` has a foot gun `readonly` does not have.
Because this point comes up repeatedly here is a concrete example:
final class PipelineOne // private(set)
{
public private(set) array $orderedPipelineSteps = [
\Thing\StepDoSomethingTwo::class,
\Thing\StepAtReportBeginning::class,
\Thing\StepDoSomethingOne::class,
];
public function describe(): array
{
\sort($this->orderedPipelineSteps); // whoopsie, should have copied first
$ordered = $this->orderedPipelineSteps;
// do stuff
return $ordered;
}
}
final readonly class PipelineTwo // readonly
{
public function __construct(
public array $orderedPipelineSteps = [
\Thing\StepDoSomethingTwo::class,
\Thing\StepAtReportBeginning::class,
\Thing\StepDoSomethingOne::class,
],
) {}
public function describe(): array
{
\sort($this->orderedPipelineSteps); // whoopsie, should have copied first
$ordered = $this->orderedPipelineSteps;
// do stuff
return $ordered;
}
}
// ###################### private(set) ######################
$one = new PipelineOne();
\var_dump($one->describe());
// array(3) {
// [0]=>
// string(27) "Thing\StepAtReportBeginning" // good, now ordered
// [1]=>
// string(24) "Thing\StepDoSomethingOne"
// [2]=>
// string(24) "Thing\StepDoSomethingTwo"
//}
\var_dump($one->orderedPipelineSteps);
// array(3) {
// [0]=>
// string(27) "Thing\StepAtReportBeginning" // whoopsie, this should NOT be first!
// [1]=>
// string(24) "Thing\StepDoSomethingOne"
// [2]=>
// string(24) "Thing\StepDoSomethingTwo"
//}
// ###################### readonly ######################
$two = new PipelineTwo();
\var_dump($two->describe());
//Fatal error: Uncaught Error: Cannot indirectly modify readonly property PipelineTwo::$orderedPipelineSteps
With `private(set)` accidental mutation is legal. With `readonly`, modification after initialisation is illegal. Both are great and useful features, but `private(set)` only controls visibility not mutation. As the above example proves, `readonly` is strict when it comes to mutation and would have prevented the bug while `private(set)` happily ignores it because mutation happens from within the class. With `readonly` it would have been surfaced that I did:
\sort($this->orderedPipelineSteps); // whoopsie, mutated
$ordered = $this->orderedPipelineSteps;
instead of:
$ordered = $this->orderedPipelineSteps;
\sort($ordered);
This alone is reason enough to use `readonly` over `private(set)`; less verbosity is a cherry on top.
Note: only to make the example copy & work without the PR branch I used constructor property promotion here. With the RFC, `PipelineTwo` can declare the property default directly, without allowing outside modification.
--
Cheers
Nick
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.
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
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
Hi
On 2026-07-13 19:52, Nick Sdot wrote:
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.
That works for me, thanks. The concern I had was just that “default values for constructor property promotion are special” and thus spelling it out once more that they are special, but that the RFC will not introduce new specialness is a good thing.
Best regards
Tim Düsterhus
Hey Tim,
On 14.07.26 00:56, Tim Düsterhus wrote:
Hi
On 2026-07-13 19:52, Nick Sdot wrote:
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.
That works for me, thanks. The concern I had was just that “default values for constructor property promotion are special” and thus spelling it out once more that they are special, but that the RFC will not introduce new specialness is a good thing.
Best regards
Tim Düsterhus
Got it. Yes, no specialities. In case you deem it necessary I could add an assertion to an existing test. Something like:
class Foo { public function __construct( public readonly string $a = 'bar') {} }
var_dump(new ReflectionClass(Foo::class)->getProperty('a')->hasDefaultValue()) // bool(false)
To me it feels just not too related, and in other reviews I got commented for over-testing.
But up to you. Feel free to let me know.
Maybe "no specialities" can "promote" you from team abstain to team yes. 
--
Cheers
Nick
Hi
On 2026-07-13 20:21, Nick Sdot wrote:
Got it. Yes, no specialities. In case you deem it necessary I could add an assertion to an existing test. Something like:
class Foo { public function __construct( public readonly string $a = 'bar') {} } var_dump(new ReflectionClass(Foo::class)->getProperty('a')->hasDefaultValue()) // bool(false)To me it feels just not too related, and in other reviews I got commented for over-testing.
But up to you. Feel free to let me know.
I don't think an extra test is necessary. I just want to be able to point folks who will inevitably run into this and raise bug reports to an official document that says “we thought about this, this is working as expected” It will also be useful for the migration guide and any other blog post about “what's new in PHP” (particularly the less well-researched or AI-written ones).
Maybe "no specialities" can "promote" you from team abstain to team yes.
Personally I've never had a desired to have this capability, so it will remain an Abstain from me to leave the decision to folks who would actually make use of it.
Best regards
Tim Düsterhus
On 04.07.26 17:03, Nick Sdot wrote:
Hey Internals,
I would like to present a tiny, five-line-removal RFC allowing default values on readonly properties.
Allowing default values on readonly class properties enables creating a strict contract for implementation property values that will not change at runtime -- as in, constant-like behaviour with contract. I would love doing that.
Please find the RFC text here: PHP: rfc:readonly_property_defaults
--
Cheers
Nick
Hey everyone,
this is my "Intent to Vote" mail; I am planning to open the vote on or around July 23th.
---
Cheers
Nick