Re: Primary Constructors

On Wed, Jun 17, 2026, at 4:32 PM, Rob Landers wrote: > Hello internals, > > I was reminded of my records RFC today, and one of the features of the > RFC was "short constructors" generally called "primary constructors" in > C#/Kotlin. > > They would look like this: > > class Point(public int $x, int $id = 0) extends Base($id); > > Which is just sugar for this: > > class Point extends Base { > public function __construct(public int $x, int $id = 0) { > parent::__construct($id); > } > } > > or this: > > class Point extends Base { > public int $x; > public function __construct(int $x, int $id = 0) { > $this->x = $x; > parent::__construct($id); > } > } > > A class with a primary constructor *may not* have a defined > __construct function. Any special initialization must be done > with > hooks: > > class Temperature( > public float $celsius { > set { > if ($value < -273.15) { > throw new ValueError('below absolute zero'); > } > $this->celsius = $value; > } > } > ) {} > > new Temperature(20.0); // ok > new Temperature(-300.0); // ValueError: below absolute zero > > I'm sending this email to the list to gather additional feedback before > pursuing a formal RFC proposal. > > — Rob I would support this, and I agree that KISS is the best way to go for now. I don't know if it makes sense to include in the initial design, but for reference here's how Kotlin handles construction: class Person(val name: String, val age: Int) { // Primary constructor, equivalent to promotion and what's proposed here. init { // Argument-less code block/method that runs after the primary constructor is assigned. // This could be useful to include for more complex cases, like where hooks are useful. } // Secondary constructor constructor(name: String): this(name, 0) { // This constructor gets called first, but is forced to call the primary constructor syntactically. // Then it can do other stuff if it wants. } } cf: https://kotlinlang.org/docs/classes.html#constructors-and-initializer-blocks I don't think we should include the "secondary constructor calls primary constructor and you have to make sure it works" logic. However, I do think we can/should consider an init block. Though how that interacts with inheritance I'm not sure yet. Putting non-trivial property hooks inside a constructor promotion is already strongly discouraged, and I would recommend continuing to discourage them even with this syntax. However, that does raise a concern that we would really benefit from some way to allow property hooks to be defined "on their own" on a property, AND link the property to a promoted constructor argument. I'm not sure off hand how we would do that, and it's somewhat tangential to this syntax, but I am pointing it out for completeness. As for the readonly/hooks incompatibility, honestly, I don't care. :-) Readonly is frequently problematic, Internals has already rejected making readonly and hooks compatible, and protected(set) gets you almost the same rules with none of the conflicts. So I'm good there. --Larry Garfield