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
