Primary Constructors

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 just realized that my examples did not demonstrate the classes with a body, but they may also have a body!

— Rob

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

Hey Rob,

I was excited about the Records RFC when I read it first. The "inline
constructors" part was one of the things I loved the most about it.
Glad to see you are picking it up as a stand-alone concept here!

Having the constructor up there makes a lot of sense to me.
Especially now with property hooks, that happen to move the constructor
down in the file a lot -- because people are used to define properties
before the constructor.
Personally, I would love to see class construction to happen at the very
top -- as proposed here.

One thing I found weird about the "inline constructors" in the Records
RFC was that it allowed primary (inline) and traditional constructors.
Good to see that it is different in this proposal.

However, I have one concern...

Making this property hooks only has the downside that the classes cannot
be readonly.
Which makes it unusable in many situations where it would be neat to use
primary constructors.

I already back then wanted to propose the following, to avoid having two
constructor types, but I think it also makes sense here because of the
readonly-issue:

readonly class Point(public int $x, int $id = 0) => { // still allows 
hooks without readonly
    // normal constructor body behaviour
} extends Base($id) {
   // class body
}

Same as in your proposal it's just sugar. I'd expect it to behave the
exact same as a normal __construct body, and the => {} to be optional.
As mentioned above, the sole benefit for me would be to have class
construction at the very top, co-located with the class definition itself.
You open a class -> you know what it consumes, and how it is
constructed. Would be awesome!

Would you be open to something like this?

--

Cheers
Nick

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