Re: [RFC] Primary Constructors

On Mon, Jun 29, 2026, at 18:59, Larry Garfield wrote: [snip] > The RFC has no mention of attributes. An example of that would be helpful, even though I > presume it's exactly what one would expect it to be. This was an oversight. I'll add the logic there. This is how they work: 1. Attributes on promoted primary-constructor params are reflected on both (just like promoted properties): 1. ReflectionParameter 2. ReflectionProperty 2. Attributes on bare params remain parameter-only. 3. Target validation is context-sensitive, matching existing constructor promotion behavior: 1. #[ParamAttr] public int $x appears on the property too, but newInstance() from ReflectionProperty errors. 2. #[PropAttr] public int $x appears on the parameter too, but newInstance() from ReflectionParameter errors. 4. Attributes before a class remain class attributes and are not copied to the synthesized constructor. The last one is debatable, but from what I can tell from grepping, putting attributes on constructors is a very rare thing (39 out of 56,546 constructors). However, class-level attributes are a more common thing. That being said, I'd be open to changing (4) to behave like properties/parameters where it gets attached to the class and the constructor. > The one addition I would ask for is to note that in Kotlin and Swift, there is a > post-primary-constructor initializer, called an init block. It has > no body, but lets you do post-property-assignment stuff. It's basically an argument-free > constructor. I think that would go a long way toward smoothing the concerns people have about this > feature being too "locked down." > > If we don't want a new keyword for it, we could allow a __construct method that has NO > arguments if there is a primary constructor. It would get called last, after everything else > (including parent constructors if appropriate) has run. (Whether it's spelled > __construct() { ]] or __construct { > }, I don't have a strong opinion.) A __construct that does take arguments > would still be a compile-time conflict with a primary constructor. > > --Larry Garfield > I believe this should be a follow-up RFC. In PHP, the child decides when to call the parent constructor — so "runs last, after parent constructors" requires defining a new sequencing contract, which is a real design decision that deserves its own discussion rather than a rider on this one. Beyond that, it also requires defining a syntax (you've sketched one approach, Nick another -- both are interesting and that's exactly why it needs its own discussion), rules (whether property lists should exist), and semantics. In essence, the description would be a large (probably half) of the current RFC. — Rob