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

Hey Rowan,

On 01.07.26 15:32, Rowan Tommins [IMSoP] wrote:
> On 1 July 2026 04:29:48 BST, Nick Sdot<[email protected]> wrote:
>> ```
>>
>> final readonly class Dog(
>>     string $name,
>> )extends Animal {
>>     parent::__construct($name);
>> }=> {
>>     // class body }
>>
>> ```
>>
>> The above:
>> - does NOT have a parent constructor shortcut call -> `extends Animal`
>> - DOES allow parent constructor call in primary constructor body
>> - behaves exactly (!) as a conventional constructor; in fact syntax sugar
>>
>> ```
>>
>> final readonly class Dog(
>>     string $name,
>> )extends Animal($name)// already IS the parent constructor call... {
>>     // hence, here no parent constructor call allowed }=> {
>>     // class body }
>>
>> ```
>>
>> The above:
>> - DOES have a parent constructor shortcut call -> `extends Animal($name)`
>> - does NOT allow parent constructor call in primary constructor body
>> - *no difference in parent constructor calling behaviour to what the RFC pr
> ooposes now*
> ...
>
>> So where is the complexity?
> So now we have to specify:
>
> - a brand new syntax for putting a code block outside the class body
> - a parser rule to detect parent conductor calls (is ParentClassName::__construct also forbidden? What about DeeperAncestor::__construct?)
> - the order of operations if there's a body and a shorthand parent call
> - maybe other details of how the constructor body works which I haven't thought of
>

As with the rest of the feature, to make the proposed changes work in 
the class header, yes. :)
Of course *any* parent constructor call would be forbidden from the body 
if the parent shorthand is used. The "already IS the parent... hence, 
here no parent..." gives no room for interpretation, I think.
The order could be discussed, and a default (probably after, because 
that's how it seem to work without body) be agreed on. Since there would 
be a body, manually calling the parent constructor would be possible if 
the default doesn't suit ones intend.

I still don't see an explosion of complexity.

>> What would justify not allowing the body that helps to address a real problem?
> Many people see having more than one way to write the same thing as a cost, which needs to be outweighed by some benefit.
>
> I'm on the fence whether primary constructors as they are in the current RFC are worthwhile; they're a tidy shorthand for a common case, but not saving that much over existing constructor promotion.
>
> With your proposal to make them just a different way of writing any constructor, using a weird new syntax which puts code outside of the class body, I would be a definite "no".
>
> That's just my opinion of the cost-benefit balance.

Bit sad to see that there is not even the will to discuss it. But fair, 
everyone can have their opinion. Then I hope the "on the fence" will 
eventually be a "no". Because there is IMO no reality where introducing 
this without bodies, and hence with no solution to the issues I pointed 
out, is easier to reason about than what I propose here. Just imagine 
you have to refactor an existing class with a primary constructor. 
`readonly` would prevent what you want to do and must be removed. This 
would require you to check and refactor the whole class, instead of just 
adding a body. It doesn't make sense.

We don't need more half finished, half not working, confusing features 
in PHP.
> Rowan Tommins
> [IMSoP]

--

Cheers
Nick