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]> 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
