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

Hey Rob,

On 01.07.26 17:43, Rob Landers wrote:
> On Wed, Jul 1, 2026, at 10:51, Nick Sdot wrote:
>>
>> Hey Rowan,
>>
>> On 01.07.26 15:32, Rowan Tommins [IMSoP] wrote:
>>> On 1 July 2026 04:29:48 BST, Nick Sdot<[email protected]> <mailto:[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
>
> Hi Nick,
>
> First of all, the fact that three people have submitted different 
> syntaxes (putting aside that I also haven’t shared my preference as 
> well), should be an indication that it isn’t straightforward; just 
> from a “what does it look like” perspective.
>
> It isn’t simply “just run this code”.
>
> I would very much ask that you move this discussion to a different 
> thread. As the RFC author, who rejected it as future scope, I can’t 
> engage with your proposal here. All I can say is that I reject it for 
> future scope, repeatedly.
>
> Moving it outside the thread would let people in this thread discuss 
> the RFC as proposed, and if there’s a consensus in the new thread, 
> perhaps it could be adopted into this RFC or even proposed as an 
> immediate following RFC.
>
> Arguing for it here, cuts off my hands and is a distraction.
>
> — Rob


As I said earlier, I disagree that this is unrelated. Calling it a 
"distraction" is... I don't know. The very feature your RFC proposes 
will create a new problem, because you hold the opinion that preexisting 
limitations could just be ignored (or moved to future scope) for a *new* 
feature. I think that is wrong, and not good for the language -- which I 
had to point out. People actively engaged with my concern in this very 
branch of the thread, I responded. That is what the list is for?  I, 
however, understand that you stick to rejecting; I will not add anything 
new and if no one else shares my concern then this branch and topic will 
naturally die down.

--

Cheers
Nick