Re: [PHP-DEV] [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