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

__
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

For anon classes, I would think the best approach is to have a compact, non-redundant syntax for "take this value from current scope and assign it to a property in this class." Basically combining promotion and closure. Doing that right now is horribly ugly.

That may well be out of scope for this RFC, and that's fine, but I wanted to put that out there.

--Larry Garfield

Hi

Am 2026-06-29 20:44, schrieb Eric Norris:

I'm afraid of going off-topic, but I disagree that "readonly is
broken." In what way is it broken? A large part of the disagreement in
the previous "readonly hooks" RFC was over the meaning of readonly.
I'd have to fully go back to remind myself of the nuance, but my
recollection is that it works exactly how I (and others, per the vote
outcome) expect.

[…]

This is not meant to be a combative email by the way, I just want to
make sure it's clear that I believe readonly is not something that we
should remove or consider baggage.

I'm in full agreement on the quoted sections.

Best regards
Tim Düsterhus

Hi

Am 2026-06-29 22:22, schrieb Rob Landers:

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):
2. ReflectionParameter
3. ReflectionProperty
4. Attributes on bare params remain parameter-only.
5. Target validation is context-sensitive, matching existing
   constructor promotion behavior:
6. #[ParamAttr] public int $x appears on the property too, but
   newInstance() from ReflectionProperty errors.
7. #[PropAttr] public int $x appears on the parameter too, but
   newInstance() from ReflectionParameter errors.
8. 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.

Thank you for confirming my assumption that expectations likely differ
(https://news-web.php.net/php.internals/131610).

I would expect #[Attr] to be applied to both Foo and
Foo::__construct() for consistency with promoted properties, since
“Primary constructors” are effectively “Promoted Constructors”:

 #[Attr]
 class Foo(public int $x) { }

The error on the newInstance() will only be an issue for code that
tries to unconditionally instantiate unknown attributes, which is bound
to fail already since attributes do not need to be backed by a class -
and arguably doing so is not super useful, since you don't know the
semantics of unknown attributes. Code that knows what a given attribute
means will not try to find it on mismatching targets and thus will not
try to instantiate them either.

Best regards
Tim Düsterhus

It's also the entire point of the feature ;) You open the file, and in two seconds, you know:

It defines two properties, type int and string, it calls parent::__construct with those two parameters.

Currently, you open the class, seek to the constructor, read it to understand if it even calls the parent constructor or not. Just like promoted properties, the cost is nominal, but now it is nearly ubiquitous in usage and saves a large amount of time in reading and writing classes. This feature seeks to do the same.

It's also the entire point of the feature ;) You open the file, and in
two seconds, you know:

It defines two properties, type int and string, it calls
parent::__construct with those two parameters.

Currently, you open the class, seek to the constructor, read it to
understand if it even calls the parent constructor or not. Just like
promoted properties, the cost is nominal, but now it is nearly
ubiquitous in usage and saves a large amount of time in reading and
writing classes. This feature seeks to do the same.

I don't think the "seek to the constructor" problem is real in practice.
By convention the constructor goes first in a PHP class, so the code
you'd be reading is simply:

class Foo extends Base
{
  public function __construct(public int $a, public string $b)
  {
    parent::__construct($a, $b);
  }
}

That's seven lines that fit comfortably on any screen, and each concept,
the class, the constructor, the promoted properties, the parent call,
sits on its own line where it's immediately recognizable. Packing all of
it onto a single line saves nothing and makes the code harder to read,
not easier.

I also disagree with comparing this to promoted properties. Promoted
properties removed genuine boilerplate: the property declaration, the
constructor parameter, and the $this->x = $x assignment collapsed into
one place because they were the same information repeated three times.
Primary constructors don't remove repetition; they just relocate the
constructor signature into the class declaration line. There's no
duplicated information being eliminated.

Cheers,
Seifeddine.