Re: [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<php@nicksdot.dev> 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