Re: [PHP-DEV] [RFC] Primary Constructors

Hey Rob,

On 29.06.26 21:35, Rob Landers wrote:
> On Mon, Jun 29, 2026, at 13:42, Nick Sdot wrote:
>>
>> Hey Rob,
>>
>> On 29.06.26 19:03, Rob Landers wrote:
>>> Hi, Nick,
>>>
>>> On Mon, Jun 29, 2026, at 10:47, Nick Sdot wrote:
>>>> Hey Rowan,
>>>>
>>>> On 29.06.26 16:00, Rowan Tommins [IMSoP] wrote:
>>>> > On 29/06/2026 07:31, Nick Sdot wrote:
>>>> >>
>>>> >> If "use conventional constructors, if you need `readonly` classes"
>>>> >> stands, then the same can be argued for everything else in the RFC.
>>>> >>
>>>> >
>>>> > For the record, my view is completely the opposite: if the new 
>>>> syntax
>>>> > allows everything a normal constructor does, just in a slightly
>>>> > different position, it will lead to endless style discussions of 
>>>> which
>>>> > to use.
>>>>
>>>>
>>>> That's a fair opinion, and not unexpected. Personally, I oppose
>>>> introducing more inconsistencies to PHP. Looks like that we need to 
>>>> have
>>>> these discussions then?
>>>
>>> There's no inconsistency here.
>>
>> The inconsistency is that we will have two kind of constructors. One 
>> that has a body, one has not. It's a completely new concept, but you 
>> talk about syntax sugar.
>
> There's only one constructor; PHP doesn't allow you to have different 
> constructors. You choose the spelling that makes the most sense for 
> your class and objectives. This is just declaration, not logic.
Dude...
>
>>> It only prevents you from initialization/validation in a body 
>>> because there are no bodies. 
>>
>>
>> Right. Which makes them useless in endless situations.
>>
>
> Of all the PHP code on my machine (production application code, 
> frameworks like symfony/laravel/doctrine) ... it's about 30-40% of all 
> constructors that are completely empty. I also sent an LLM to look 
> further at things that could benefit from this (ie, promote properties 
> on older code instead of just empty constructors). It came back with 
> 71% of Laravel and 61% of Symfony that could use Primary Constructors. 
> I'm not saying they should go rewrite their code or anything like 
> that, but that basically means at least 1-2 out of 3 classes written 
> in a given codebase could use primary constructors to simplify their 
> construction and make it easier to skim.
>
> My 2¢: I don't think this is useless.
I did not say it is useless, I did say it is useless in endless 
situations. And it is avoidable, by allowing a body.
>>> If you need a body, use a constructor -- that's what they're for. 
>>
>> But then I cannot benefit from the position (at the top of the class) 
>> of the primary constructors, which I really would like. Shouldn't we 
>> try to make each new feature as useful as possible? What are the 
>> actual blockers to not support primary constructor bodies?
>
> There is nothing preventing a follow-up RFC from being proposed, but 
> as well as anonymous classes, it deserves its own RFC. There's a lot 
> of syntax to bike-shed, as well as questions like "if I give a body, 
> can I still use a parent constructor shortcut?" It is not 
> straightforward and nor should it be. I fully explored this in the 
> Records RFC, and many people pushed back on the logic, even pointed 
> out unsoundness in what seemed like an otherwise sound design.

Well, this is going to be more of a general thing, nothing exclusive to 
your RFC... But this is how we end up with more and more half finished 
and awkward (to not say broken) features in PHP. While I understand and 
generally support "get the minimum in and iterate later" from the 
perspective of RFC authors, reality shows that "later" can be either 
years later or very likely never at all. Though, we will have to deal 
with the unfinished/broken "minimum" solutions. How many more of these 
do we want to add?

To name three from the top of my mind:
1/ we still don't have stringable enums
2/ we still don't have a solution for widening the type of a promoted 
property's set hooks (hi #16638), and of course
3/ my beloved readonly hooks themselves. ;)

You know, I don't argue for the sake of it. It's just too often that my 
concerns turn out to be valid, eventually. See my comment to #16638; we 
probably should just have skipped hooks on promoted properties unless 
there would have been a solution before release. Now we have to deal 
with this inconsistent and broken behaviour for forever (?), because 
people are already busy with the next features. If we already not get 
such features right (no blame to anyone -- it's complex!), imagine what 
a disaster introducing native inline generics (with all its "good follow 
up RFC") could have lead to, if they would have made it in the language 
before PHP even has the will to agree on an internals approved official 
PHPDoc types spec that can prove itself over a few years without 
breaking code.

Point is, I care. That's why I voice my concerns.

> "if I give a body, can I still use a parent constructor shortcut?"

My opinion: usage of parent constructor shortcut forbids manual parent 
constructor calling, and vice versa. Makes sense to me, and sounds easy 
to reason about.

Other people could see that different, yes. But that's why I think it 
should be discussed *now*, instead of postponing to likely never, and 
then again have a "half nice" feature to deal with. Will the discussions 
be more complex? Yes. Will they take much longer? Yes. Could it lead to 
that the feature doesn't get in at all, not even in the minimum version? 
Yes. But I am honestly at a point where I think that's a good thing. 
Better nothing than yet another "mid" one that is annoying.
>>> The RFC makes it plain that bodies are rejected and why.
>>
>> It's possible that I missed where the "why" was explained, but I 
>> don't see explanations apart from "expressed in property hooks"; 
>> which I am here pointing out will not work in readonly classes. Could 
>> you please make the "why" more clear in the RFC?
>
> Will do.
>>> If you can provide a concrete reason why they should be allowed with 
>>> a completely new syntax, that would be a good follow-up RFC; or even 
>>> a competing one. If you disagree with the reasoning, I'd love to 
>>> hear it.
>>
>> The concrete reason is what I already mentioned: it will not work 
>> with readonly classes and `private(set)` is not the same.
>> It's not that readonly for value projects is a rare thing.
>
> Where do you see in the RFC that it won't work with readonly classes, 
> because that would be an error on my part? It explicitly does not 
> prevent you from using any type of class except enums. If you're 
> referring to the usage of primary constructors in combination with 
> hooks and readonly, that's an orthogonal issue that belongs to the 
> interaction between hooks and readonly and is far out of scope from 
> this RFC. That is a limitation that exists today and this RFC does not 
> strive to address it.

Respectfully, your answer is misleading. The limitation exist, yes. But 
with your proposal you introduce a new layer to the problem that your 
proposal of course should strive to address. Conventional constructors 
do have a body that allow working around the limitation. You intend to 
add new syntax that deliberately prevents a workaround by not allowing a 
body. So, please, "not my beer" is a little too blunt here. How the 
feature is proposed makes it less adaptable, and again introduces new 
gotchas. Bad for us, bad for the language.

Should harder discussions, caused by body behaviour, really be a reason 
to add another "well, just good enough" in?

--

Cheers
Nick