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. >> 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. >> 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. >> 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. > >> — Rob > -- > > Cheers > Nick > — Rob
