[RFC] Primary Constructors

Hey Rowan,

If "use conventional constructors, if you need readonly classes"
stands, then the same can be argued for everything else in the RFC.

For the record, my view is completely the opposite: if the new syntax
allows everything a normal constructor does, just in a slightly
different position, it will lead to endless style discussions of which
to use.

That's a fair opinion, and not unexpected. Personally, I oppose
introducing more inconsistencies to PHP. Looks like that we need to have
these discussions then?

In fact, I don't think even property hooks belong in a primary
constructor; they're ugly enough in a constructor promoted property.

It's a feature that was accepted to PHP and exists already. So it
doesn't really matter whether we (I agree -- shouldn't be used for
anything more than eg a neat callback) find it ugly and we have to deal
with its existence. You are basically making a point for allowing
primary constructor bodies. Having them allows to have a readonly
classes with primary constructors, and assign properties in their body.
Neat.

I think it's perfectly fine to have short-hands that only cover
specific use cases, and longer forms that let you express more complex
use cases. It's one of the reasons I voted against the recent RFC to
allow an extra reassignment of properties in the constructor
[https://wiki.php.net/rfc/promoted_readonly_constructor_reassign].

For the record, my view is completely the opposite: without allowing
primary constructor bodies the added value of adding the new syntax is
nearly non-existent.

Quoting from your message in the first thread to this:

I don't think we should add extra syntax to the language just to
change people's habits. If you want a constructor body as the first
thing in the class, you can do that right now.

...because the exact argument can be made from either point of view. To
quote you again: "all or nothing"; bodies should be allowed.

--

Cheers
Nick

Hello internals,

I'd like to put forward Primary Constructors
https://wiki.php.net/rfc/primary-constructors for comment.

An implementation PR will be opened later today (UTC), and the RFC updated
with this discussion thread.

— Rob

I don't see any mention of anonymous classes, I assume they aren't
compatible syntax wise?

Hi Lynn,

That's a good observation! Originally, I had a whole section and decided
to strip it, then forgot to add it back as non-supported and future scope.
FWIW, I was originally going to support them with something like:

$arg = 'foo';
$class = new class(public int $x = $arg) {}

Which desugars to:

$arg = 'foo';
$class = new class($arg) {
public function __construct(public int $x) {}
}

There are a lot of caveats, which is why I dropped it for future scope:

1. it would require types on the input parameters to disambiguate
   between arguments and properties
2. it gets weird if you don't specify a default value for the property
   and makes it ambiguous as a constructor
3. which begs the question of always having a default

In essence, it deserves its own RFC because there is a lot of subtlety and
only makes sense in the context that primary constructors exist in the
first place.

I'll address it in the RFC, thanks!

— Rob

I think the only thing that needs to be solved for anonymous classes would
be the syntax. Seeing there's always a visibility/type in property
promotion, I think it should be clear it's going to be style (A) or (B)
based on the syntax as you can't mix. I can't see a scenario where you
would write:

$class = new class(public int $x) {}

Where as the following would be just fine:

$class = new class(public int $x = 0) {}; // construct with
property $x being 0
$class = new class(public int|null $x = null) {}; // construct with
property $x being null
$class = new class(public int $x = $x) {}; // construct with
$x from local scope into property $x
$class = new class(public int $x = $this->x) {}; // construct with
$this->x from the instance scope
$class = new class(public int $x = self::$x) {}; // construct with
$this->x from the static self scope

Bonus points if the body becomes optional:

$class = new class(public int $x = 0, public int $y = 0);

This would be the existing style and remains unchanged

$class = new class($localScope) {};

Mixing would error as you can't pick both:

$class = new class(public int $x = 0, $y) {}; // Nothing handles $y as
no body is allowed
$class = new class($x, public int $y = 0) {}; // Can't allow the
latter as $x requires a body to do something

Perhaps this isn't as simple as I think it is, but this would be a nice +
to have in this RFC. I think it's fine to keep the initial implementation
rather restrictive, it can always be improved upon in the future.

FWIW, I was originally going to support them with something like:

$arg = 'foo';
$class = new class(public int $x = $arg) {}

Which desugars to:

$arg = 'foo';
$class = new class($arg) {
public function __construct(public int $x) {}
}

I actually have a draft RFC kicking around for this, but using a different syntax inspired by closures:

$arg = 'foo';
$class = new class() use (public int $arg) {}

This allows a very concise version for very simple cases:

$class = new class() use ($arg) {}

I even had a working implementation, but paused it to work out if a constructor could be allowed as well. If the syntax allowed for a parent constructor call, though, that might be enough for most use cases.

Although it's not obvious, anonymous classes are actually compiled once, and then constructed multiple times, which means the syntax is doing quite a lot more than constructor promotion.

I agree that it should be left as future scope to pin down exactly how it should look and work.

Rowan Tommins
[IMSoP]