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

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.
> It only prevents you from initialization/validation in a body because 
> there are no bodies. 


Right. Which makes them useless in endless situations.

> 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?
> 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?
> 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.

> — Rob

--

Cheers
Nick