Re: [RFC] Primary Constructors

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 > 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. Rowan Tommins [IMSoP]