Re: [RFC] Primary Constructors

On 30.06.26 03:47, Rob Landers wrote:

On Mon, Jun 29, 2026, at 21:20, Nick Sdot wrote:

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.

The irony here is that this is a follow-up RFC born weeks after someone reminded me about this part of it. It was abandoned due to comments like this. I do think I have a track record of attempting interesting RFCs and then abandoning them because it's clear nobody wants them. And that's fine. As I've stated multiple times in this thread, it would explode the complexity of the RFC. Probably half of it would just be about constructors. That's clear it should be a separate RFC, and if I did present it, you (or someone else) would argue that it needs to be broken up -- just like the records RFC. I show up, because I care as well; but damn, everyone can't always have cake. — Rob I loved the Records RFC -- see my comments on Twitter about it -- and I would not have asked you to break it up. But I would have asked why we need both inline and conventional constructors in the same time, instead of just the genius inline (now primary) constructors with a body. ;)

My intention is not to demotivate you, fwiw. Keen to talk about the complexity. -- Cheers Nick